Hi, Having listened to the two presentations on scheduled LSPs in PCE and one in TEAS I think we need to do some architectural work and make sure we are all on the same page.
This work probably needs to be squared off across the two WGs and possibly also MPLS. The architectural question is "Where is future scheduled resource reservation data held?" The options are: i. Solely in a centralised DB ii. In several distributed DBs that might be periodically synchronised iii. Distributed into the network iv. Some combination of the above. In the old world, the management system held all information about connections in the network. Such management systems were able to schedule connection establishment as well since they had a full view of all resources and all connections. In MPLS/GMPLS, the pendulum swung. Connection state was held in the network and not widely known. Only current resource availability was distributed. In such systems, scheduled connections required a management system that could access the current resource availability and plan the scheduled connections. But this approach was vulnerable to connections set up by other entities (in a distributed manner) that might "steal" resources needed for a planned future connection. One of the proposed solutions to this problem is that scheduled state is distributed into the network by signaling. That is, an RSVP Path message includes the timing parameters and the resources can be reserved by the network devices for use at the specified time. The disadvantages of this approach are that the network nodes have to have per-resource time-based databases (which may be quite complex), and that other nodes in the network (such as other head-end nodes, or PCEs) do not know about the future reservations. The answer to the second point is to report the future reservations either in PCEP or in the IGP. Doing it in the IGP means that every node in the network can see the future reservations, but may have an interesting scaling impact. Doing it in PCEP means the PCE is in synch with the network, but doesn't help other LSRs so implies a PCE-controlled scheduling system. At this point we might ask why, if the resource scheduling is controlled by the PCE, we need to distribute the scheduling information in the network. Why not just leave the time-based TED in the PCE? That reduces us to adding time parameters to the PCReq, but no changes to the PCInitiate message. The PCRep might have some time-based stuff for confirmation etc. But, this approach would have no changes to the RSVP messages. The above is me just rambling on the topic a bit, but it seems that we need to get all of this work on the same page and agree the architecture of what we are trying to build. Thanks for listening, Adrian _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
