1 / 17

(Slide set by Norvald Stol/Steinar Bjørnstad 2013)

(Slide set by Norvald Stol/Steinar Bjørnstad 2013). Outline. Introduction Enhancements to signaling - Hierarchical LSP setup - The suggested label - Bidirectional LSP setup - Notify messages

cynthia-nichols
Download Presentation

(Slide set by Norvald Stol/Steinar Bjørnstad 2013)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. (Slide set by Norvald Stol/Steinar Bjørnstad 2013)

  2. Outline • Introduction • Enhancements to signaling- Hierarchical LSP setup- The suggested label- Bidirectional LSP setup- Notify messages • GMPLS protection and Restoration techniques- Protection mechanisms (Span/Path protection)- Restoration mechanisms • Conclusions

  3. Introduction • IP -> MPLS => Datagram to Virtual Connection (VC)(point-to-point) • Explicitly routed label switched paths (LSPs) established before information transport – independent of actual routing paradigm • Label swapping used as forwarding paradigm • Forwarding equivalence classes (FECs) • Label hierarchy / Label stacking

  4. Introduction (2) • Constraint based routing- traffic engineering (QoS differentiation)- fast reroute (after failure)- diversity routing (disjoint alternative paths for protection) • Routing protocols (e.g. OSPF) must exchange sufficient information for ”constraint” • Resource reservation protocol with traffic engineering (RSVP-TE) is used to establish LSP/label forwarding states along path.(The alternative CR-LDP is not used any more)

  5. Introduction (3) Generalized MPLS: • Extensions to handle e.g. optical network resources (OXC’s) (e.g. extensions of OSPF, RSVP-TE). • Common control plane for packet and optical network • New Link Management Protocol (LMP) for optical links. • Support for (label) switching in time, wavelength and space domains – and a label hierarchy. • Additional functionality to handle bidirectional links and protection/restoration.

  6. RSVP-TE and OSPF enhancements • RSVP-TE (CR-LDP) • Initiate optical channel trails • For optical networks and other connection oriented networks • OSPF (IS-IS) • Advertise availability of resources • Bandwidth of wavelengths • Interface types • Other network attributes and constraints

  7. Enhancements to signaling • Control plane may be physically diverse from the data plane. • Hierarchical LSPs (Study the example in the article to see what establishing a new LSP may entail, start with LSP1) • The suggested label: • An upstream node suggests an optimal label (fast) • May be overridden by its downstream node (slower) - In optical networks with limited wavelength conversion • Suggested wavelength (-label) to use isvery useful

  8. Enhancements to signaling (2) Bidirectional LSP setup (New in GMPLS): • Bidirectional optical LSPs (lightpaths) are important for network operators • Fate sharing • Protection and restoration • Same QoS in both directions, same resource demands Problems with two independent LSPs in MPLS: • Additional delay in set-up (problem in protection) • Race conditions for scarce resources => lower probability of success for both directions simultaneously • Twice the control overhead In GMPLS: Single set of Path/Request and Resv/Mapping messages used to establish LSPs in both directions at once.

  9. Enhancements to signaling (3) Notify messages: • Added to RSVP-TE for GMPLS • Provides a mechanism for informing nonadjacent nodes of LSP-related failures. • Inform nodes responsible for restoring connection • Avoid processing in intermediate nodes • Speed up • Failure detection and reaction • Re-establishment of normal operation

  10. GMPLS Protection and Restoration Four primary steps of fault management: • Detection- should be handled at layer closest to failure, i.e. optical layer. E.g. ”Loss-of-light” (LOL), Bit Error Ratio, .. • Localization- requires communication between nodes. LMP includes procedure for fault localization. • Channel fail message over separate control channel • Notification- Notify message added to RSVP-TE signaling • Mitigation • “Repairing the failure”

  11. GMPLS Protection and Restoration (2) • Path switching (End-to-end) • Failures addressed at path end-points • Line switching (local) • Action at intermediate transit nodes where the failure is detected • Prot and rest. Terms not precisely defined: In practice used for fault handling in different time frames. • ”Protection” • Fast • usually pre-allocated resources to handle failures quickly, • e.g. SDH/SONET: 50 ms – 100% extra resources and simultaneous transmission. (1+1 protection)

  12. GMPLS Restoration • When fault is handled after a failure has occurred • Dynamic resource allocation • Usually at least one order of magnitude higher delay than protection • Different levels of ”preparedness” • Pre-calculated routes or not; • Some resources reserved or not

  13. GMPLS Protection and Restoration (3) Protection mechanisms: • 1+1 protection: simultaneous transmission of data on two different paths. • M:N protection: M preallocated back-up paths shared by N connections. (1:N is most usual; 1:1 also relevant). • Span protection – between adjacent nodes (NB! Avoid ”fate sharing”):

  14. GMPLS Protection and Restoration (4) • 1+1 Path protection (disjoint paths): • For M:N Path protection: back-up paths may be used for lower priority traffic in normal operation – preemption (Supported by GMPLS)

  15. GMPLS Protection and Restoration (5) • Restoration mechanisms: • Alternative paths may be computed beforehand, but resources are seldom allocated before they are needed.

  16. Conclusion • GMPLS is a good idea and do have a lot of nice functionality to handle the networks of the future!

More Related