1 / 16

Application of PWE3 to MPLS Transport Networks

This draft discusses the application of PWE3 (Pseudowire Emulation Edge-to-Edge) to MPLS (Multiprotocol Label Switching) transport networks, focusing on the requirements, configuration, and OAM (Operations, Administration, and Maintenance) mechanisms. It also addresses the concerns about T-MPLS (Transport MPLS) departing from the IETF design without proper signaling. The purpose of this draft is to document the transport MPLS requirements and propose solutions using existing IETF RFCs.

charlesgonzales
Télécharger la présentation

Application of PWE3 to MPLS Transport Networks

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. Application of PWE3 to MPLS Transport Networks draft-bryant-pwe3-mpls-transport-00 {stbryant,mmorrow,tnadeau,swallow}@cisco.com cherukuri@juniper.net

  2. Background • For some time ITU SG15 has been working on the design of a mechanism to provide an MPLS server layer for use in the construction of transport networks. • (A transport network is the network that IETF thinks of as the physical network, i.e. Ethernet, SONET rings etc) • The ITU proposal is to provide multi-layer virtualization of the transport network through the use of pseudowires and MPLS label stacking. • This mechanism is known as T-MPLS (Transport MPLS)

  3. Liaison, Interims and Plenary • ITU SG15 liaised their design to the IETF very late in the standardisation process – specifically after the design completed it’s main approval state. • There were a number of liaison statements that passed between the IETF and ITU SG15, two interim meetings and an ITU SG15 plenary that is currently underway. • The Interims and Plenary were variously attended by both MPLS WG chairs, one of the PWE3 WG chairs, one CCAMP chair and one of the routing ADs. • As a result of these discussions a number of violations of invariants in the MPLS architecture were identified and corrected. • The phase 1 T-MPLS design will go for final consent this Friday, and final consent is almost certain.

  4. Fundamental Concern • T-MPLS has been described in various ITU meetings as a sub-set of PWE3 + MPLS and as an extended subset. • Although other groups have cast the PWE3 + MPLS design in there own language, these groups have always worked very closely with the IETF at all stages, and both the intent and the outcome has always been bit-for-bit semantic compatibility. (I.e., there have been no extensions or variations). • T-MPLS uses the same Ethertypes as MPLS/PWE3. • The fundamental concern therefore is that the T-MPLS variant of pseudowire over MPLS will in some way, and at some time, depart from the IETF design without any way for the network to know which variant it is operating.

  5. Purpose of this draft • Prior to the IETF involvement no attempt had been made to document the transport MPLS requirements. • At one of the interim meeting, SG15 Q12 were persuaded to document the transport MPLS requirements, and these were liaised to the IETF. • The purpose of this draft is to describe how those requirements can be met using existing IETF RFCs without modification.

  6. Key Requirements • No merging • No PHP • The PHP requirement derives from the OAM desired on the PSN tunnel (there is no PHP on the PWE3 label). • Bidirectional & unidirectional pt-pt with reciprocal paths. • Unidirectional multi-point paths. • Ability to operate without IP in the network. • Configuration may be via an external NMS. • Phase 1 requirements restricted to pt-pt Ethernet PWs

  7. Application PWE3 to MPLS Transport Networks IP/MPLS PSN (PHP may be enabled) MPLS PSN (No PHP) 802.3 802.3 CE1 PE1 PE2 CE2 MPLS PSN (no PHP) Pseudowire 802.3 (Ethernet) IP/MPLS LSP (PHP may be supported)

  8. PWE3 Configuration • Encapsulation is Ethernet [RFC4448], used in "raw" mode. • The Control Word MUST be used. • The Sequence number MUST be zero. • Pseudowire Label is statically provisioned. • Pseudowire Setup and Maintenance Label Distribution Protocol [RFC4447] is not supported.

  9. PW OAM • The OAM mechanism is VCCV [VCCV]. • One of the following VCCV profiles MUST be used: • BFD without IP/UDP Headers • BFD with IP/UDP Headers

  10. VCCV profile 1: BFD without IP/UDP Headers • The first nibble is set to 0001b to indicate a pseudowire associated channel. • The Version and the Reserved fields are set to 0, the Version is 0. • Channel Type is set to 0x07 to indicate that the payload carried in BFD without IP/UDP headers • The connection verification method used by VCCV is BFD with diagnostics as defined in 4.1

  11. VCCV profile 2: BFD with IP/UDP Headers • May be used when the PEs are IP capable and have been configured with IP addresses. • The first nibble is set to 0001b to indicate a pseudowire associated channel. • The Version and the Reserved fields are set to 0, the Version is 0. • The Channel Type is set to 0x21 for IPv4 and 0x56 for IPv6 payloads. • The connection verification method used by VCCV is BFD with diagnostics as defined in 4.1 of [VCCV].

  12. MPLS Configuration • The profile considers two cases: • The case where external configuration is used • The case where a control plane is available

  13. External MPLS Configuration • All MPLS labels MUST be statically provisioned. • Labels may be selected from the per-platform or per-interface label space. • All LSPs MUST support both unidirectional and bi-directional point-to-point connections. • LSPs SHOULD support unidirectional point-to-multipoint connections. • The forward and backward directions of a bi-directional connection should follow the same path along the transport LSP. • Equal cost multi-path (ECMP) load balancing MUST NOT be configured . • The Merging of label switched paths is prohibited and MUST NOT be configured. • Penultimate hop popping by the LSRs MUST be disabled . • Both E-LSP and L-LSP MUST be supported. • The MPLS EXP field is supported according to RFC3270 for only when the pipe and short-pipe models are utilized.

  14. Control Plane MPLS Configuration • Profile applies when RSVP-TE or the bi-directional support in GMPLS are used to configure the MPLS PSN • The following are automatically provided: • There is no label merging unless it is deliberately enabled to support Fast Re-route (FRR). • A single path is provided end-to-end (There is no ECMP). • Paths may be unidirectional or bidirectional as required. • The following configurations restrictions MUST be applied: • Penultimate hop popping by the LSRs MUST be disabled. • Both E-LSP and L-LSP MUST be supported. • The MPLS EXP field is supported according to RFC3270 for only when the pipe and short-pipe models are utilized.

  15. MPLS OAM • The draft needs more work to specify the MPLS OAM. • Note that the requirement is that this OAM be able to operate without the use of IP.

  16. Next Steps • Please read the draft and the liaisons, particularly the requirements for the use of MPLS in transport networks. • The PWE3 WG needs to consider what it wishes to do next: • Do we wish to adopt this topic as a WG item? • Is this draft a suitable starting point? • Do we wish to adopt this draft? • Do we liaise this draft to ITU SG15 Q12?

More Related