Transcript PPT Version

Application of PWE3 to MPLS
Transport Networks
draft-bryant-pwe3-mpls-transport-00
{stbryant,mmorrow,tnadeau,swallow}@cisco.com
[email protected]
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)
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.
Fundamental Concern
• T-MPLS has been described in various ITU meetings as a subset 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.
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.
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
Application PWE3 to MPLS
Transport Networks
IP/MPLS PSN (PHP may be enabled)
MPLS PSN (No PHP)
802.3
CE1
802.3
PE1
PE2
MPLS PSN (no PHP)
Pseudowire
802.3 (Ethernet)
IP/MPLS LSP (PHP may be supported)
CE2
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.
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
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
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].
MPLS Configuration
• The profile considers two cases:
– The case where external configuration is
used
– The case where a control plane is available
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-topoint 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.
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.
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.
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:
1.
2.
3.
4.
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?