1 / 12

RFC 3031: Multiprotocol Label Switching Architecture Chapter 3.27 – 3.30

RFC 3031: Multiprotocol Label Switching Architecture Chapter 3.27 – 3.30. 2005/07/14 (Thu) Shinichi Ishida. 3.27. Tunnels and Hierarchy. Ru takes explicit action to deliver packet to Rd, even though Ru&Rd is not consecutive and Rd is not the ultimate destination

sawyer
Download Presentation

RFC 3031: Multiprotocol Label Switching Architecture Chapter 3.27 – 3.30

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. RFC 3031: Multiprotocol Label Switching ArchitectureChapter 3.27 – 3.30 2005/07/14 (Thu) Shinichi Ishida

  2. 3.27. Tunnels and Hierarchy Ru takes explicit action to deliver packet to Rd, even though Ru&Rd is not consecutive and Rd is not the ultimate destination => encapsulate the packet inside a network layer • Hop-by-Hop Routed Tunnel Tunneled Packet follows the Hop-by-Hop path • Explicitly Routed Tunnel Tunneled Packet travels over a path other than the Hop-by-Hop path

  3. 3.27.3. LSP Tunnels implemeting a tunnel as a LSP use label switching rather than network layer encapsulation the set of packets through the LSP tunnel constitutes a FEC, each LSR in the tunnel must assign a label to that FEC.

  4. R1 R2 R3 R4 IP IP L L R23 R21 R22 IP IP L L IP 3.27.4. Hierarchy: LSP Tunnels within LSPs

  5. R2 R3 R1 R21 3.27.5. (1/3)Label Distribition Peering and Hierarchy when two LSRs are IGP neighbors > local label distibution peers not IGP neighbors > remote … IGP neighbors

  6. 3.27.5. (2/3)Label Distribition Peering and Hierarchy • Explicit Peering distribute labels by sending messages which are addressed to the peer useful when the number of remote peer is small the number of higher level label bindings is large the remote peers are in distinct routing areas

  7. 3.27.5. (3/3)Label Distribition Peering and Hierarchy • Implicit Peering - encode a higher level label as an attribute of a lower label - distribute the lower leve label to local peers - local peers propagate the information to their local peers - continue till the information reaches the remote peer useful when the number of remote peers is large (not require n-square peering mesh)

  8. 3.28. Label Distribution Protocol Transport label distribution protocol : establish and maintain the label binding Needs: reliability, in sequence, flow control use TCP as the underlying transport [MPLS-LDP] [MPLS-BGP]

  9. 3.29. Why More than one Label Distribution Protocol ? ‘which’ label distribution protocol to use in ‘which’ circumstances ? # this architecture does NOT establish hard and fast rules for choosing point out some of the considerations in the following sections (3.29.1 – 3.29.3)

  10. 3.29.1. BGP and LDP desirable to bind labels to FECs idetified with routes to address prefixes If there is a standard, widely deployed routing algorithm -> label distribution is best achived by piggybacking on that ex) BGP a number of advantages RR:significant scalability

  11. 3.29.2. Labels for RSVP Flowspecs When RSVP is used for particular flows desirable to label the packets in those flows → RSVP filterspec: not need to be applied at each hop most efficient method of distributing labels = having RSVP distribute the labels as part of its path/reservation setup process ?

  12. 3.29.3. Labels for Explicitly Routed LSPs It is desirable for traffic engineering - to set up an explicitly routed path - to apply resource reservations along that path • two approaches

More Related