draft-ietf-mpls-tp-framework-09.txt   draft-ietf-mpls-tp-framework-10.txt 
MPLS Working Group M. Bocci, Ed. MPLS Working Group M. Bocci, Ed.
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Informational S. Bryant, Ed. Intended status: Informational S. Bryant, Ed.
Expires: August 1, 2010 D. Frost Expires: August 8, 2010 D. Frost, Ed.
Cisco Systems Cisco Systems
L. Levrau L. Levrau
Alcatel-Lucent Alcatel-Lucent
L. Berger L. Berger
LabN LabN
January 28, 2010 February 4, 2010
A Framework for MPLS in Transport Networks A Framework for MPLS in Transport Networks
draft-ietf-mpls-tp-framework-09 draft-ietf-mpls-tp-framework-10
Abstract Abstract
This document specifies an architectural framework for the This document specifies an architectural framework for the
application of Multiprotocol Label Switching (MPLS) to the application of Multiprotocol Label Switching (MPLS) to the
construction of packet-switched transport networks. It describes a construction of packet-switched transport networks. It describes a
common set of protocol functions - the MPLS Transport Profile common set of protocol functions - the MPLS Transport Profile
(MPLS-TP) - that supports the operational models and capabilities (MPLS-TP) - that supports the operational models and capabilities
typical of such networks, including signalled or explicitly typical of such networks, including signaled or explicitly
provisioned bi-directional connection-oriented paths, protection and provisioned bi-directional connection-oriented paths, protection and
restoration mechanisms, comprehensive Operations, Administration and restoration mechanisms, comprehensive Operations, Administration and
Maintenance (OAM) functions, and network operation in the absence of Maintenance (OAM) functions, and network operation in the absence of
a dynamic control plane or IP forwarding support. Some of these a dynamic control plane or IP forwarding support. Some of these
functions are defined in existing MPLS specifications, while others functions are defined in existing MPLS specifications, while others
require extensions to existing specifications to meet the require extensions to existing specifications to meet the
requirements of the MPLS-TP. requirements of the MPLS-TP.
This document defines the subset of the MPLS-TP applicable in general This document defines the subset of the MPLS-TP applicable in general
and to point-to-point paths. The remaining subset, applicable and to point-to-point paths. The remaining subset, applicable
skipping to change at page 2, line 21 skipping to change at page 2, line 21
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 1, 2010. This Internet-Draft will expire on August 8, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 5 skipping to change at page 3, line 5
1.3.1. Transport Network . . . . . . . . . . . . . . . . . . 6 1.3.1. Transport Network . . . . . . . . . . . . . . . . . . 6
1.3.2. MPLS Transport Profile . . . . . . . . . . . . . . . . 7 1.3.2. MPLS Transport Profile . . . . . . . . . . . . . . . . 7
1.3.3. MPLS-TP Section . . . . . . . . . . . . . . . . . . . 7 1.3.3. MPLS-TP Section . . . . . . . . . . . . . . . . . . . 7
1.3.4. MPLS-TP Label Switched Path . . . . . . . . . . . . . 7 1.3.4. MPLS-TP Label Switched Path . . . . . . . . . . . . . 7
1.3.5. MPLS-TP Label Switching Router (LSR) and Label 1.3.5. MPLS-TP Label Switching Router (LSR) and Label
Edge Router (LER) . . . . . . . . . . . . . . . . . . 7 Edge Router (LER) . . . . . . . . . . . . . . . . . . 7
1.3.6. Customer Edge (CE) . . . . . . . . . . . . . . . . . . 8 1.3.6. Customer Edge (CE) . . . . . . . . . . . . . . . . . . 8
1.3.7. Edge-to-Edge LSP . . . . . . . . . . . . . . . . . . . 8 1.3.7. Edge-to-Edge LSP . . . . . . . . . . . . . . . . . . . 8
1.3.8. Service LSP . . . . . . . . . . . . . . . . . . . . . 8 1.3.8. Service LSP . . . . . . . . . . . . . . . . . . . . . 8
1.3.9. Layer Network . . . . . . . . . . . . . . . . . . . . 8 1.3.9. Layer Network . . . . . . . . . . . . . . . . . . . . 8
1.3.10. Additional Definitions and Terminology . . . . . . . . 8 1.3.10. Additional Definitions and Terminology . . . . . . . . 9
1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 9 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 9
2. MPLS Transport Profile Requirements . . . . . . . . . . . . . 11 2. MPLS Transport Profile Requirements . . . . . . . . . . . . . 11
3. MPLS Transport Profile Overview . . . . . . . . . . . . . . . 12 3. MPLS Transport Profile Overview . . . . . . . . . . . . . . . 12
3.1. Packet Transport Services . . . . . . . . . . . . . . . . 12 3.1. Packet Transport Services . . . . . . . . . . . . . . . . 12
3.2. Scope of the MPLS Transport Profile . . . . . . . . . . . 13 3.2. Scope of the MPLS Transport Profile . . . . . . . . . . . 13
3.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . 14 3.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1. MPLS-TP Client Adaptation Functions . . . . . . . . . 14 3.3.1. MPLS-TP Client Adaptation Functions . . . . . . . . . 14
3.3.2. MPLS-TP Forwarding Functions . . . . . . . . . . . . . 15 3.3.2. MPLS-TP Forwarding Functions . . . . . . . . . . . . . 15
3.4. MPLS-TP Native Services . . . . . . . . . . . . . . . . . 16 3.4. MPLS-TP Native Services . . . . . . . . . . . . . . . . . 16
3.4.1. MPLS-TP Client/Server Relationship . . . . . . . . . . 17 3.4.1. MPLS-TP Client/Server Relationship . . . . . . . . . . 17
skipping to change at page 3, line 27 skipping to change at page 3, line 27
3.4.3. Network Layer Adaptation . . . . . . . . . . . . . . . 21 3.4.3. Network Layer Adaptation . . . . . . . . . . . . . . . 21
3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 25 3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 25
3.6. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 25 3.6. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 25
3.7. Operations, Administration and Maintenance (OAM) . . . . . 28 3.7. Operations, Administration and Maintenance (OAM) . . . . . 28
3.8. LSP Return Path . . . . . . . . . . . . . . . . . . . . . 30 3.8. LSP Return Path . . . . . . . . . . . . . . . . . . . . . 30
3.8.1. Return Path Types . . . . . . . . . . . . . . . . . . 31 3.8.1. Return Path Types . . . . . . . . . . . . . . . . . . 31
3.8.2. Point-to-Point Unidirectional LSPs . . . . . . . . . . 31 3.8.2. Point-to-Point Unidirectional LSPs . . . . . . . . . . 31
3.8.3. Point-to-Point Associated Bidirectional LSPs . . . . . 32 3.8.3. Point-to-Point Associated Bidirectional LSPs . . . . . 32
3.8.4. Point-to-Point Co-Routed Bidirectional LSPs . . . . . 32 3.8.4. Point-to-Point Co-Routed Bidirectional LSPs . . . . . 32
3.9. Control Plane . . . . . . . . . . . . . . . . . . . . . . 32 3.9. Control Plane . . . . . . . . . . . . . . . . . . . . . . 32
3.10. Inter-domain Connectivity . . . . . . . . . . . . . . . . 34 3.10. Inter-domain Connectivity . . . . . . . . . . . . . . . . 35
3.11. Static Operation of LSPs and PWs . . . . . . . . . . . . . 35 3.11. Static Operation of LSPs and PWs . . . . . . . . . . . . . 35
3.12. Survivability . . . . . . . . . . . . . . . . . . . . . . 35 3.12. Survivability . . . . . . . . . . . . . . . . . . . . . . 35
3.13. Path Segment Tunnels . . . . . . . . . . . . . . . . . . . 36 3.13. Path Segment Tunnels . . . . . . . . . . . . . . . . . . . 37
3.13.1. Provisioning of PST . . . . . . . . . . . . . . . . . 37 3.13.1. Provisioning of PST . . . . . . . . . . . . . . . . . 38
3.14. Pseudowire Segment Tunnels . . . . . . . . . . . . . . . . 38 3.14. Pseudowire Segment Tunnels . . . . . . . . . . . . . . . . 38
3.15. Network Management . . . . . . . . . . . . . . . . . . . . 38 3.15. Network Management . . . . . . . . . . . . . . . . . . . . 38
4. Security Considerations . . . . . . . . . . . . . . . . . . . 39 4. Security Considerations . . . . . . . . . . . . . . . . . . . 39
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 40 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 41
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.1. Normative References . . . . . . . . . . . . . . . . . . . 40 8.1. Normative References . . . . . . . . . . . . . . . . . . . 41
8.2. Informative References . . . . . . . . . . . . . . . . . . 43 8.2. Informative References . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
1.1. Motivation and Background 1.1. Motivation and Background
This document describes an architectural framework for the This document describes an architectural framework for the
application of MPLS to the construction of packet-switched transport application of MPLS to the construction of packet-switched transport
networks. It specifies the common set of protocol functions that networks. It specifies the common set of protocol functions that
meet the requirements in [RFC5654], and that together constitute the meet the requirements in [RFC5654], and that together constitute the
skipping to change at page 6, line 19 skipping to change at page 6, line 19
LSP Label Switched Path LSP Label Switched Path
MPLS-TP MPLS Transport Profile MPLS-TP MPLS Transport Profile
SDH Synchronous Digital Hierarchy SDH Synchronous Digital Hierarchy
ATM Asynchronous Transfer Mode ATM Asynchronous Transfer Mode
OTN Optical Transport Network OTN Optical Transport Network
cl-ps Connectionless - Packet Switched cl-ps Connectionless - Packet Switched
co-cs Connection Oriented - Circuit Switched co-cs Connection Oriented - Circuit Switched
co-ps Connection Oriented - Packet Switched co-ps Connection Oriented - Packet Switched
OAM Operations, Administration and Maintenance OAM Operations, Administration and Maintenance
G-ACh Generic Associated Channel G-ACh Generic Associated Channel
GAL Generic Alert Label GAL G-ACh Label
MEP Maintenance End Point MEP Maintenance End Point
MIP Maintenance Intermediate Point MIP Maintenance Intermediate Point
APS Automatic Protection Switching APS Automatic Protection Switching
SCC Signalling Communication Channel SCC Signaling Communication Channel
MCC Management Communication Channel MCC Management Communication Channel
EMF Equipment Management Function EMF Equipment Management Function
FM Fault Management FM Fault Management
CM Configuration Management CM Configuration Management
PM Performance Management PM Performance Management
LSR Label Switching Router LSR Label Switching Router
MPLS-TP PE MPLS-TP Provider Edge LSR MPLS-TP PE MPLS-TP Provider Edge LSR
MPLS-TP P MPLS-TP Provider LSR MPLS-TP P MPLS-TP Provider LSR
PW Pseudowire PW Pseudowire
AC Attachment Circuit
Adaptation The mapping of client information into a format suitable Adaptation The mapping of client information into a format suitable
for transport by the server layer for transport by the server layer
Native The traffic belonging to the client of the MPLS-TP network Native The traffic belonging to the client of the MPLS-TP network
Service Service
T-PE PW Terminating Provider Edge T-PE PW Terminating Provider Edge
S-PE PW Switching provider Edge S-PE PW Switching provider Edge
1.3.1. Transport Network 1.3.1. Transport Network
A Transport Network provides transparent transmission of client user A Transport Network provides transparent transmission of client user
skipping to change at page 8, line 38 skipping to change at page 8, line 41
1.3.6. Customer Edge (CE) 1.3.6. Customer Edge (CE)
A Customer Edge (CE) is the client function sourcing or sinking A Customer Edge (CE) is the client function sourcing or sinking
native service traffic to or from the MPLS-TP network. CEs on either native service traffic to or from the MPLS-TP network. CEs on either
side of the MPLS-TP network are peers and view the MPLS-TP network as side of the MPLS-TP network are peers and view the MPLS-TP network as
a single point-to-point or point-to-multipoint link. a single point-to-point or point-to-multipoint link.
1.3.7. Edge-to-Edge LSP 1.3.7. Edge-to-Edge LSP
An Edge-to-Edge LSP is an LSP between a pair of PEs that may transit An Edge-to-Edge LSP is an LSP between a pair of PEs that may transit
zero of more provider LSRs. zero or more provider LSRs.
1.3.8. Service LSP 1.3.8. Service LSP
A service LSP is an LSP that caries a single client service. A service LSP is an LSP that carries a single client service.
1.3.9. Layer Network 1.3.9. Layer Network
A layer network is defined in [G.805] and described in [RFC5654]. A layer network is defined in [G.805] and described in [RFC5654].
1.3.10. Additional Definitions and Terminology 1.3.10. Additional Definitions and Terminology
Detailed definitions and additional terminology may be found in Detailed definitions and additional terminology may be found in
[RFC5654]. [RFC5654].
skipping to change at page 12, line 9 skipping to change at page 12, line 9
Point to point LSPs may be unidirectional or bi-directional, and it Point to point LSPs may be unidirectional or bi-directional, and it
must be possible to construct congruent Bi-directional LSPs. must be possible to construct congruent Bi-directional LSPs.
MPLS-TP LSPs do not merge with other LSPs at an MPLS-TP LSR and it MPLS-TP LSPs do not merge with other LSPs at an MPLS-TP LSR and it
must be possible to detect if a merged LSP has been created. must be possible to detect if a merged LSP has been created.
It must be possible to forward packets solely based on switching the It must be possible to forward packets solely based on switching the
MPLS or PW label. It must also be possible to establish and maintain MPLS or PW label. It must also be possible to establish and maintain
LSPs and/or pseudowires both in the absence or presence of a dynamic LSPs and/or pseudowires both in the absence or presence of a dynamic
control plane. When static provisioning is used, there must be no control plane. When static provisioning is used, there must be no
dependency on dynamic routing or signalling. dependency on dynamic routing or signaling.
OAM, protection and forwarding of data packets must be able to OAM, protection and forwarding of data packets must be able to
operate without IP forwarding support. operate without IP forwarding support.
It must be possible to monitor LSPs and pseudowires through the use It must be possible to monitor LSPs and pseudowires through the use
of OAM in the absence of control plane or routing functions. In this of OAM in the absence of control plane or routing functions. In this
case information gained from the OAM functions is used to initiate case information gained from the OAM functions is used to initiate
path recovery actions at either the PW or LSP layers. path recovery actions at either the PW or LSP layers.
3. MPLS Transport Profile Overview 3. MPLS Transport Profile Overview
skipping to change at page 13, line 27 skipping to change at page 13, line 27
3.2. Scope of the MPLS Transport Profile 3.2. Scope of the MPLS Transport Profile
Figure 4 illustrates the scope of MPLS-TP. MPLS-TP solutions are Figure 4 illustrates the scope of MPLS-TP. MPLS-TP solutions are
primarily intended for packet transport applications. MPLS-TP is a primarily intended for packet transport applications. MPLS-TP is a
strict subset of MPLS, and comprises only those functions that are strict subset of MPLS, and comprises only those functions that are
necessary to meet the requirements of [RFC5654]. This includes MPLS necessary to meet the requirements of [RFC5654]. This includes MPLS
functions that were defined prior to [RFC5654] but that meet the functions that were defined prior to [RFC5654] but that meet the
requirements of [RFC5654], together with additional functions defined requirements of [RFC5654], together with additional functions defined
to meet those requirements. Some MPLS functions defined before to meet those requirements. Some MPLS functions defined before
[RFC5654] such as Equal Cost Multi-Path, LDP signalling used in such [RFC5654] such as Equal Cost Multi-Path, LDP signaling used in such a
a way that it creates multipoint-to-point LSPs, and IP forwarding in way that it creates multipoint-to-point LSPs, and IP forwarding in
the data plane are explicitly excluded from MPLS-TP by that the data plane are explicitly excluded from MPLS-TP by that
requirements specification. requirements specification.
Note that MPLS as a whole will continue to evolve to include Note that MPLS as a whole will continue to evolve to include
additional functions that do not conform to the MPLS Transport additional functions that do not conform to the MPLS Transport
Profile or its requirements, and thus fall outside the scope of Profile or its requirements, and thus fall outside the scope of
MPLS-TP. MPLS-TP.
|<============================== MPLS ==============================>| |<============================== MPLS ==============================>|
skipping to change at page 14, line 12 skipping to change at page 14, line 12
{ Transport } { Transport }
{ Functions } { Functions }
Figure 4: Scope of MPLS-TP Figure 4: Scope of MPLS-TP
3.3. Architecture 3.3. Architecture
MPLS-TP comprises the following architectural elements: MPLS-TP comprises the following architectural elements:
o A standard MPLS data plane [RFC3031] as profiled in o A standard MPLS data plane [RFC3031] as profiled in
[draft-fbb-mpls-tp-data-plane]. [I-D.fbb-mpls-tp-data-plane].
o Sections, LSPs and PWs that provide a packet transport service for o Sections, LSPs and PWs that provide a packet transport service for
a client network. a client network.
o Proactive and on-demand Operations, Administration and Maintenance o Proactive and on-demand Operations, Administration and Maintenance
(OAM) functions to monitor and diagnose the MPLS-TP network, such (OAM) functions to monitor and diagnose the MPLS-TP network, such
as connectivity check, connectivity verification, performance as connectivity check, connectivity verification, performance
monitoring and fault localisation. monitoring and fault localisation.
o Optional control planes for LSPs and PWs, as well as support for o Optional control planes for LSPs and PWs, as well as support for
skipping to change at page 15, line 52 skipping to change at page 15, line 52
encapsulation. A swap of this label is an atomic operation in which encapsulation. A swap of this label is an atomic operation in which
the contents of the packet after the swapped label are opaque to the the contents of the packet after the swapped label are opaque to the
forwarder. The only event that interrupts a swap operation is TTL forwarder. The only event that interrupts a swap operation is TTL
expiry. This is a fundamental architectural construct of MPLS to be expiry. This is a fundamental architectural construct of MPLS to be
taken into account when designing protocol extensions that require taken into account when designing protocol extensions that require
packets (e.g. OAM packets) to be sent to an intermediate LSR. packets (e.g. OAM packets) to be sent to an intermediate LSR.
Further processing to determine the context of a packet occurs when a Further processing to determine the context of a packet occurs when a
swap operation is interrupted in this manner, or a pop operation swap operation is interrupted in this manner, or a pop operation
exposes a specific reserved label at the top of the stack, or the exposes a specific reserved label at the top of the stack, or the
packet is received with the GAL Section 3.6 at the top of stack. packet is received with the GAL (Section 3.6) at the top of stack.
Otherwise the packet is forwarded according to the procedures in Otherwise the packet is forwarded according to the procedures in
[RFC3032]. [RFC3032].
Point-to-point MPLS-TP LSPs can be either unidirectional or Point-to-point MPLS-TP LSPs can be either unidirectional or
bidirectional. bidirectional.
It must be possible to configure an MPLS-TP LSP such that the forward It must be possible to configure an MPLS-TP LSP such that the forward
and backward directions of a bidirectional MPLS-TP LSP are co-routed, and backward directions of a bidirectional MPLS-TP LSP are co-routed,
i.e. follow the same path. The pairing relationship between the i.e. follow the same path. The pairing relationship between the
skipping to change at page 16, line 39 skipping to change at page 16, line 39
definition and processing rules of [RFC5462] and [RFC3270]. Note definition and processing rules of [RFC5462] and [RFC3270]. Note
that packet reordering between flows belonging to different traffic that packet reordering between flows belonging to different traffic
classes may occur if more than one traffic class is supported on a classes may occur if more than one traffic class is supported on a
single LSP. single LSP.
Only the Pipe and Short Pipe DiffServ tunnelling and TTL processing Only the Pipe and Short Pipe DiffServ tunnelling and TTL processing
models described in [RFC3270] and [RFC3443] are supported in MPLS-TP. models described in [RFC3270] and [RFC3443] are supported in MPLS-TP.
3.4. MPLS-TP Native Services 3.4. MPLS-TP Native Services
This document describes the architecture for two types of native This document describes the architecture for two native service
service adaptation: adaptation mechanisms, which provide encapsulation and demultiplexing
for native service traffic traversing an MPLS-TP network:
o A PW: PW Demultiplexer and PW encapsulation
o An MPLS Label (for example carrying a layer 2 VPN [RFC4664], a o A PW
layer 3 VPN [RFC4364], or a TE-LSP [RFC3209])
o An IP packet o An MPLS Label
A PW provides any emulated service that the IETF has defined to be A PW provides any emulated service that the IETF has defined to be
provided by a PW, for example Ethernet, Frame Relay, or PPP/HDLC. A provided by a PW, for example Ethernet, Frame Relay, or PPP/HDLC. A
registry of PW types is maintained by IANA. When the client registry of PW types is maintained by IANA. When the native service
adaptation is via a PW, the mechanisms described in Section 3.4.2 are adaptation is via a PW, the mechanisms described in Section 3.4.2 are
used. used.
An MPLS LSP Label can also be used as the adaptation, in which case An MPLS LSP Label can also be used as the adaptation, in which case
any client supported by [RFC3031] is allowed, for example a MPLS LSP, any native service traffic type supported by [RFC3031] and [RFC3032]
PW, or IP. When the client adaptation is via an MPLS label, the is allowed. Examples of such traffic types include IP, and MPLS-
mechanisms described in Section 3.4.3 are used. labeled packets. Note that the latter case includes TE-LSPs
[RFC3209] and LSP based applications such as PWs, Layer 2 VPNs
[RFC4664], and Layer 3 VPNs [RFC4364]. When the native service
adaptation is via an MPLS label, the mechanisms described in
Section 3.4.3 are used.
3.4.1. MPLS-TP Client/Server Relationship 3.4.1. MPLS-TP Client/Server Relationship
The MPLS-TP client server relationship is defined by the MPLS-TP The MPLS-TP client server relationship is defined by the MPLS-TP
network boundary and the label context. It is not explicitly network boundary and the label context. It is not explicitly
indicated in the packet. In terms of the MPLS label stack, when the indicated in the packet. In terms of the MPLS label stack, when the
client traffic type of the MPLS-TP network is an MPLS LSP or a PW, client traffic type of the MPLS-TP network is an MPLS LSP or a PW,
then the S bits of all the labels in the MPLS-TP label stack carrying then the S bits of all the labels in the MPLS-TP label stack carrying
that client traffic are zero; otherwise the bottom label of the that client traffic are zero; otherwise the bottom label of the
MPLS-TP label stack has the S bit set to one (i.e. there can only one MPLS-TP label stack has the S bit set to 1 (i.e. there can only one S
S bit set in a label stack). bit set in a label stack).
The data plane behaviour of MPLS-TP is the same as the best current The data plane behaviour of MPLS-TP is the same as the best current
practise for MPLS. This includes the setting of the S-Bit. In each practise for MPLS. This includes the setting of the S-Bit. In each
case, the S-bit is set to indicate the bottom (i.e. inner-most) label case, the S-bit is set to indicate the bottom (i.e. inner-most) label
in the label stack that is contiguous between the MPLS-TP server and in the label stack that is contiguous between the MPLS-TP server and
the client layer. Note that this best current practise differs the client layer. Note that this best current practise differs
slightly from [RFC3032] which uses the S-bit to identify when MPLS slightly from [RFC3032] which uses the S-bit to identify when MPLS
label processing stops and network layer processing starts. label processing stops and network layer processing starts.
The relationship of MPLS-TP to its clients is illustrated in The relationship of MPLS-TP to its clients is illustrated in
skipping to change at page 20, line 31 skipping to change at page 20, line 31
| P-router | | P-router |
| | | |
|<-------------------- Emulated Service ------------------->| |<-------------------- Emulated Service ------------------->|
PW1-segment1 and PW1-segment2 are segments of the same MS-PW, PW1-segment1 and PW1-segment2 are segments of the same MS-PW,
while PW2-segment1 and PW2-segment2 are segments of another MS-PW while PW2-segment1 and PW2-segment2 are segments of another MS-PW
Figure 7: MPLS-TP Architecture (Multi-Segment PW) Figure 7: MPLS-TP Architecture (Multi-Segment PW)
The corresponding MPLS-TP protocol stacks including PWs are shown in The corresponding MPLS-TP protocol stacks including PWs are shown in
Figure 8. In this figure protocol the Transport Service Layer Figure 8. In this figure the Transport Service Layer [RFC5654] is
[RFC5654] is identified by the PW demultiplexer (Demux) label and the identified by the PW demultiplexer (Demux) label and the Transport
Transport Path Layer [RFC5654] is identified by the LSP Demux Label. Path Layer [RFC5654] is identified by the LSP Demux Label.
+-------------------+ /===================\ /===================\ +-------------------+ /===================\ /===================\
| Client Layer | H OAM PDU H H OAM PDU H | Client Layer | H OAM PDU H H OAM PDU H
/===================\ H-------------------H H-------------------H /===================\ H-------------------H H-------------------H
H PW Encap H H GACh H H GACh H H PW Encap H H GACh H H GACh H
H-------------------H H-------------------H H-------------------H H-------------------H H-------------------H H-------------------H
H PW Demux (S=1) H H PW Demux (S=1) H H GAL (S=1) H H PW Demux (S=1) H H PW Demux (S=1) H H GAL (S=1) H
H-------------------H H-------------------H H-------------------H H-------------------H H-------------------H H-------------------H
H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H
\===================/ \===================/ \===================/ \===================/ \===================/ \===================/
| Server Layer | | Server Layer | | Server Layer | | Server Layer | | Server Layer | | Server Layer |
+-------------------+ +-------------------+ +-------------------+ +-------------------+ +-------------------+ +-------------------+
User Traffic PW OAM LSP OAM User Traffic PW OAM LSP OAM
Note: H(ighlighted) indicates the part of the protocol stack we are Note: H(ighlighted) indicates the part of the protocol stack we are
considering in this document. considering in this document.
Figure 8: MPLS-TP Layer Network using Pseudowires Figure 8: MPLS-TP Layer Network using Pseudowires
PWs and their underlying labels may be configured or signaled. See PWs and their associated labels may be configured or signaled. See
Section 3.11 for additional details related to configured service Section 3.11 for additional details related to configured service
types. See Section 3.9 for additional details related to signaled types. See Section 3.9 for additional details related to signaled
service types. service types.
3.4.2.1. Pseudowire Bases Services 3.4.2.1. Pseudowire Based Services
When providing a Virtual Private Wire Service (VPWS) , Virtual When providing a Virtual Private Wire Service (VPWS) , Virtual
Private Local Area Network Service (VPLS), Virtual Private Multicast Private Local Area Network Service (VPLS), Virtual Private Multicast
Service (VPMS) or Internet Protocol Local Area Network Service (IPLS) Service (VPMS) or Internet Protocol Local Area Network Service
pseudowires must be used to carry the client service. VPWS, VLPS, (IPLS), pseudowires must be used to carry the client service. VPWS,
and IPLS are described in [RFC4664]. VPMS is described in VLPS, and IPLS are described in [RFC4664]. VPMS is described in
[I-D.ietf-l2vpn-vpms-frmwk-requirements] [I-D.ietf-l2vpn-vpms-frmwk-requirements].
3.4.3. Network Layer Adaptation 3.4.3. Network Layer Adaptation
MPLS-TP LSPs can be used to transport network layer clients. This MPLS-TP LSPs can be used to transport network layer clients. This
document uses the term Network Layer in the same sense as it is used document uses the term Network Layer in the same sense as it is used
in [RFC3031] and [RFC3032]. The network layer protocols supported by in [RFC3031] and [RFC3032]. The network layer protocols supported by
[RFC3031] and [RFC3032] can be transported between service [RFC3031] and [RFC3032] can be transported between service
interfaces. Examples are shown in Figure 5 above. Support for interfaces. Examples are shown in Figure 5 above. Support for
network layer clients follows the MPLS architecture for support of network layer clients follows the MPLS architecture for support of
network layer protocols as specified in [RFC3031] and [RFC3032]. network layer protocols as specified in [RFC3031] and [RFC3032].
skipping to change at page 24, line 22 skipping to change at page 24, line 22
For example, if only MPLS labeled packets are carried over a service, For example, if only MPLS labeled packets are carried over a service,
then the Service Label (stack entry) provides both the payload type then the Service Label (stack entry) provides both the payload type
indication and service identification. indication and service identification.
Service labels are typically carried over an MPLS-TP LSP edge-to-edge Service labels are typically carried over an MPLS-TP LSP edge-to-edge
(or transport path layer). An MPLS-TP edge-to-edge LSP is (or transport path layer). An MPLS-TP edge-to-edge LSP is
represented as an LSP Demux label as shown in Figure 10. An edge-to- represented as an LSP Demux label as shown in Figure 10. An edge-to-
edge LSP is commonly used when more than one service exists between edge LSP is commonly used when more than one service exists between
two PEs. two PEs.
Note, the edge-to-edge LSP may be omitted when only one service Note that the edge-to-edge LSP may be omitted when only one service
exists between two PEs. For example, if only one service is carried exists between two PEs. For example, if only one service is carried
between two PEs then a single Service Label could be used to provide between two PEs then a single Service Label could be used to provide
both the service indication and the MPLS-TP edge-to-edge LSP. both the service indication and the MPLS-TP edge-to-edge LSP.
Alternatively, if multiple services exist between a pair of PEs then Alternatively, if multiple services exist between a pair of PEs then
a per-client Service Label would be mapped on to a common MPLS-TP a per-client Service Label would be mapped on to a common MPLS-TP
edge-to-edge LSP. edge-to-edge LSP.
As noted above, the layer 2 and layer 1 protocols used to carry the As noted above, the layer 2 and layer 1 protocols used to carry the
network layer protocol over the attachment circuits are not network layer protocol over the attachment circuits are not
transported across the MPLS-TP network. This enables the use of transported across the MPLS-TP network. This enables the use of
skipping to change at page 24, line 46 skipping to change at page 24, line 46
At each service interface, Layer 2 addressing must be used to ensure At each service interface, Layer 2 addressing must be used to ensure
the proper delivery of a network layer packet to the adjacent node. the proper delivery of a network layer packet to the adjacent node.
This is typically only an issue for LAN media technologies (e.g., This is typically only an issue for LAN media technologies (e.g.,
Ethernet) which have Media Access Control (MAC) addresses. In cases Ethernet) which have Media Access Control (MAC) addresses. In cases
where a MAC address is needed, the sending node must set the where a MAC address is needed, the sending node must set the
destination MAC address to an address that ensures delivery to the destination MAC address to an address that ensures delivery to the
adjacent node. That is the CE sets the destination MAC address to an adjacent node. That is the CE sets the destination MAC address to an
address that ensures delivery to the PE, and the PE sets the address that ensures delivery to the PE, and the PE sets the
destination MAC address to an address that ensures delivery to the destination MAC address to an address that ensures delivery to the
CE. The specific address used is technology type specific and is not CE. The specific address used is technology type specific and is not
covered in this document. In some technologies the MAC address will specified in this document. In some technologies the MAC address
need to be configured (Examples for the Ethernet case include a will need to be configured. (Examples for the Ethernet case include
configured unicast MAC address for the adjacent node, or even using a configured unicast MAC address for the adjacent node, or even using
the broadcast MAC address when the CE-PE service interface is the broadcast MAC address when the CE-PE service interface is
dedicated. The configured address is then used as the MAC dedicated. The configured address is then used as the destination
destination address for all packets sent over the service interface.) MAC address for all packets sent over the service interface.)
Note that when two CEs, which peer with each other, operate over a Note that when two CEs, which peer with each other, operate over a
network layer transport service run a routing protocol such as IS-IS network layer transport service and run a routing protocol such as
or OSPF some care should be taken to configure the routing protocols IS-IS or OSPF, some care should be taken to configure the routing
to use point- to-point adjacencies .The specifics of such protocols to use point-to-point adjacencies. The specifics of such
configuration is outside the scope of this document. See [RFC5309] configuration is outside the scope of this document. See [RFC5309]
for additional details. for additional details.
The CE to CE service types and corresponding labels may be configured The CE to CE service types and corresponding labels may be configured
or signaled . See Section 3.11 for additional details related to or signaled . See Section 3.11 for additional details related to
configured service types. See Section 3.9 for additional details configured service types. See Section 3.9 for additional details
related to signaled service types. related to signaled service types.
3.5. Identifiers 3.5. Identifiers
skipping to change at page 25, line 31 skipping to change at page 25, line 31
[I-D.ietf-mpls-tp-identifiers] defines a set of identifiers that are [I-D.ietf-mpls-tp-identifiers] defines a set of identifiers that are
compatible with existing MPLS control plane identifiers, as well as a compatible with existing MPLS control plane identifiers, as well as a
set of identifiers that may be used when no IP control plane is set of identifiers that may be used when no IP control plane is
available. available.
3.6. Generic Associated Channel (G-ACh) 3.6. Generic Associated Channel (G-ACh)
For correct operation of the OAM it is important that the OAM packets For correct operation of the OAM it is important that the OAM packets
fate-share with the data packets. In addition in MPLS-TP it is fate-share with the data packets. In addition in MPLS-TP it is
necessary to discriminate between user data payloads and other types necessary to discriminate between user data payloads and other types
of payload. For example, a packet may be associated with a of payload. For example, a packet may be associated with a Signaling
Signalling Communication Channel (SCC), or a channel used for Communication Channel (SCC), or a channel used for Automatic
Automatic Protection Switching (APS) data. This is achieved by Protection Switching (APS) data. This is achieved by carrying such
carrying such packets on a generic control channel associated to the packets on a generic control channel associated to the LSP, PW or
LSP, PW or section. section.
MPLS-TP makes use of such a generic associated channel (G-ACh) to MPLS-TP makes use of such a generic associated channel (G-ACh) to
support Fault, Configuration, Accounting, Performance and Security support Fault, Configuration, Accounting, Performance and Security
(FCAPS) functions by carrying packets related to OAM, APS, SCC, MCC (FCAPS) functions by carrying packets related to OAM, APS, SCC, MCC
or other packet types in-band over LSPs or PWs. The G-ACh is defined or other packet types in-band over LSPs or PWs. The G-ACh is defined
in [RFC5586] and is similar to the Pseudowire Associated Channel in [RFC5586] and is similar to the Pseudowire Associated Channel
[RFC4385], which is used to carry OAM packets over pseudowires. The [RFC4385], which is used to carry OAM packets over pseudowires. The
G-ACh is indicated by a generic associated channel header (ACH), G-ACh is indicated by a generic associated channel header (ACH),
similar to the Pseudowire VCCV control word; this header is present similar to the Pseudowire VCCV control word; this header is present
for all Sections, LSPs and PWs making use of FCAPS functions for all Sections, LSPs and PWs making use of FCAPS functions
skipping to change at page 26, line 16 skipping to change at page 26, line 16
bottom of stack label then have a defined format called an associated bottom of stack label then have a defined format called an associated
channel header (ACH), which further defines the content of the channel header (ACH), which further defines the content of the
packet. The ACH is therefore both a demultiplexer for G-ACh traffic packet. The ACH is therefore both a demultiplexer for G-ACh traffic
on the PW, and a discriminator for the type of G-ACh traffic. on the PW, and a discriminator for the type of G-ACh traffic.
When the OAM or other control message is carried over an LSP, rather When the OAM or other control message is carried over an LSP, rather
than over a pseudowire, it is necessary to provide an indication in than over a pseudowire, it is necessary to provide an indication in
the packet that the payload is something other than a user data the packet that the payload is something other than a user data
packet. This is achieved by including a reserved label with a value packet. This is achieved by including a reserved label with a value
of 13 in the label stack. This reserved label is referred to as the of 13 in the label stack. This reserved label is referred to as the
'Generic Alert Label (GAL)', and is defined in [RFC5586]. When a GAL 'G-ACh Label (GAL)', and is defined in [RFC5586]. When a GAL is
is found, it indicates that the payload begins with an ACH. The GAL found, it indicates that the payload begins with an ACH. The GAL is
is thus a demultiplexer for G-ACh traffic on the LSP, and the ACH is thus a demultiplexer for G-ACh traffic on the LSP, and the ACH is a
a discriminator for the type of traffic carried on the G-ACh. Note discriminator for the type of traffic carried on the G-ACh. Note
however that MPLS-TP forwarding follows the normal MPLS model, and however that MPLS-TP forwarding follows the normal MPLS model, and
that a GAL is invisible to an LSR unless it is the top label in the that a GAL is invisible to an LSR unless it is the top label in the
label stack. The only other circumstance under which the label stack label stack. The only other circumstance under which the label stack
may be inspected for a GAL is when the TTL has expired. Any MPLS-TP may be inspected for a GAL is when the TTL has expired. Any MPLS-TP
component that intentionally performs this inspection must assume component that intentionally performs this inspection must assume
that it is asynchronous with respect to the forwarding of other that it is asynchronous with respect to the forwarding of other
packets. All operations on the label stack are in accordance with packets. All operations on the label stack are in accordance with
[RFC3031] and [RFC3032]. [RFC3031] and [RFC3032].
In MPLS-TP, the 'G-ACh Alert Label (GAL)' always appears at the In MPLS-TP, the 'G-ACh Label (GAL)' always appears at the bottom of
bottom of the label stack (i.e. S bit set to 1). the label stack (i.e. its S bit is set to 1).
The G-ACh must only be used for channels that are an adjunct to the The G-ACh must only be used for channels that are an adjunct to the
data service. Examples of these are OAM, APS, MCC and SCC, but the data service. Examples of these are OAM, APS, MCC and SCC, but the
use is not restricted to these services. The G-ACh must not be used use is not restricted to these services. The G-ACh must not be used
to carry additional data for use in the forwarding path, i.e. it must to carry additional data for use in the forwarding path, i.e. it must
not be used as an alternative to a PW control word, or to define a PW not be used as an alternative to a PW control word, or to define a PW
type. type.
At the server layer, bandwidth and QoS commitments apply to the gross At the server layer, bandwidth and QoS commitments apply to the gross
traffic on the LSP, PW or section. Since the G-ACh traffic is traffic on the LSP, PW or section. Since the G-ACh traffic is
skipping to change at page 28, line 46 skipping to change at page 28, line 46
[RFC4379] and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have defined [RFC4379] and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have defined
alert mechanisms that enable an MPLS LSR to identify and process MPLS alert mechanisms that enable an MPLS LSR to identify and process MPLS
OAM packets when the OAM packets are encapsulated in an IP header. OAM packets when the OAM packets are encapsulated in an IP header.
These alert mechanisms are based on TTL expiration and/or use an IP These alert mechanisms are based on TTL expiration and/or use an IP
destination address in the range 127/8 for IPv4 and that same range destination address in the range 127/8 for IPv4 and that same range
embedded as IPv4 mapped IPv6 addresses for IPv6 [RFC4379]. When the embedded as IPv4 mapped IPv6 addresses for IPv6 [RFC4379]. When the
OAM packets are encapsulated in an IP header, these mechanisms are OAM packets are encapsulated in an IP header, these mechanisms are
the default mechanisms for MPLS networks in general for identifying the default mechanisms for MPLS networks in general for identifying
MPLS OAM packets. MPLS-TP must be able to operate in an environments MPLS OAM packets. MPLS-TP must be able to operate in an environments
where IP forwarding is not supported, and thus the GACH/GAL is the where IP forwarding is not supported, and thus the G-ACh/GAL is the
default mechanism to demultiplex OAM packets in MPLS-TP. default mechanism to demultiplex OAM packets in MPLS-TP.
MPLS-TP supports a comprehensive set of OAM capabilities for packet MPLS-TP supports a comprehensive set of OAM capabilities for packet
transport applications, with equivalent capabilities to those transport applications, with equivalent capabilities to those
provided in SONET/SDH. provided in SONET/SDH.
MPLS-TP defines mechanisms to differentiate specific packets (e.g. MPLS-TP defines mechanisms to differentiate specific packets (e.g.
OAM, APS, MCC or SCC) from those carrying user data packets on the OAM, APS, MCC or SCC) from those carrying user data packets on the
same transport path (i.e. section, LSP or PW). These mechanisms are same transport path (i.e. section, LSP or PW). These mechanisms are
described in [RFC5586]. described in [RFC5586].
MPLS-TP requires [I-D.ietf-mpls-tp-oam-requirements] that a set of MPLS-TP requires [I-D.ietf-mpls-tp-oam-requirements] that a set of
OAM capabilities is available to perform fault management (e.g. fault OAM capabilities is available to perform fault management (e.g. fault
detection and localisation) and performance monitoring (e.g. packet detection and localisation) and performance monitoring (e.g. packet
delay and loss measurement) of the LSP, PW or section. The framework delay and loss measurement) of the LSP, PW or section. The framework
for OAM in MPLS-TP is specified in [I-D.ietf-mpls-tp-oam-framework]. for OAM in MPLS-TP is specified in [I-D.ietf-mpls-tp-oam-framework].
MPLS-TP OAM packets share the same fate as their corresponding data MPLS-TP OAM packets share the same fate as their corresponding data
packets, and are identified through the Generic Associated Channel packets, and are identified through the Generic Associated Channel
mechanism [RFC5586]. This uses a combination of an Associated mechanism [RFC5586]. This uses a combination of an Associated
Channel Header (ACH) and a Generic Alert Label (GAL) to create a Channel Header (ACH) and a G-ACh Label (GAL) to create a control
control channel associated to an LSP, Section or PW. channel associated to an LSP, Section or PW.
OAM and monitoring in MPLS-TP is based on the concept of maintenance OAM and monitoring in MPLS-TP is based on the concept of maintenance
entities, as described in [I-D.ietf-mpls-tp-oam-framework]. A entities, as described in [I-D.ietf-mpls-tp-oam-framework]. A
Maintenance Entity can be viewed as the association of two Maintenance Entity can be viewed as the association of two
Maintenance End Points (MEPs). A Maintenance Entity Group (MEG) is a Maintenance End Points (MEPs). A Maintenance Entity Group (MEG) is a
collection of one or more MEs that belongs to the same transport path collection of one or more MEs that belongs to the same transport path
and that are maintained and monitored as a group. The MEPs that form and that are maintained and monitored as a group. The MEPs that form
an ME limit the OAM responsibilities of an OAM flow to within the an ME limit the OAM responsibilities of an OAM flow to within the
domain of a transport path or segment, in the specific layer network domain of a transport path or segment, in the specific layer network
that is being monitored and managed. that is being monitored and managed.
skipping to change at page 30, line 7 skipping to change at page 30, line 7
management of MPLS-TP Sections (between MPLS LSRs). management of MPLS-TP Sections (between MPLS LSRs).
o A LSP Maintenance Entity (LME), allowing monitoring and management o A LSP Maintenance Entity (LME), allowing monitoring and management
of an edge-to-edge LSP (between LERs). of an edge-to-edge LSP (between LERs).
o A PW Maintenance Entity (PME), allowing monitoring and management o A PW Maintenance Entity (PME), allowing monitoring and management
of an edge-to-edge SS/MS-PWs (between T-PEs). of an edge-to-edge SS/MS-PWs (between T-PEs).
o An LSP Tandem Connection Maintenance Entity (LTCME). o An LSP Tandem Connection Maintenance Entity (LTCME).
A G-ACH packet may be directed to an individual MIP along the path of A G-ACh packet may be directed to an individual MIP along the path of
an LSP or MS-PW by setting the appropriate TTL in the label for the an LSP or MS-PW by setting the appropriate TTL in the label for the
G-ACH packet, as per the traceroute mode of LSP Ping [RFC4379] and G-ACh packet, as per the traceroute mode of LSP Ping [RFC4379] and
the vccv-trace mode of[I-D.ietf-pwe3-segmented-pw]. Note that this the vccv-trace mode of [I-D.ietf-pwe3-segmented-pw]. Note that this
works when the location of MIPs along the LSP or PW path is known by works when the location of MIPs along the LSP or PW path is known by
the MEP. There may be circumstances where this is not the case, e.g. the MEP. There may be circumstances where this is not the case, e.g.
following restoration using a facility bypass LSP. In these cases, following restoration using a facility bypass LSP. In these cases,
tools to trace the path of the LSP may be used to determine the tools to trace the path of the LSP may be used to determine the
appropriate setting for the TTL to reach a specific MIP. appropriate setting for the TTL to reach a specific MIP.
Within an LSR or PE, MEPs and MIPs can only be placed where MPLS Within an LSR or PE, MEPs and MIPs can only be placed where MPLS
layer processing is performed on a packet. The architecture mandates layer processing is performed on a packet. The architecture mandates
that this must occur at least once. that this must occur at least once.
skipping to change at page 31, line 36 skipping to change at page 31, line 36
The first option is referred to as an "in-band" return path, the The first option is referred to as an "in-band" return path, the
second as an "out-of-band" return path. second as an "out-of-band" return path.
There are various possibilities for "out-of-band" return paths. Such There are various possibilities for "out-of-band" return paths. Such
a path may, for example, be based on ordinary IP routing. In this a path may, for example, be based on ordinary IP routing. In this
case packets would be forwarded as usual to a destination IP address case packets would be forwarded as usual to a destination IP address
associated with U. In an MPLS-TP network that is also an IP/MPLS associated with U. In an MPLS-TP network that is also an IP/MPLS
network, such a forwarding path may traverse the same physical links network, such a forwarding path may traverse the same physical links
or logical transport paths used by MPLS-TP. An out-of-band return or logical transport paths used by MPLS-TP. An out-of-band return
path may also be indirect, via a network management system; or it may path may also be indirect, via a distinct Data Communication Network
be via one or more other MPLS-TP LSPs. (DCN) (provided, for example, by the method specified in [RFC5718]);
or it may be via one or more other MPLS-TP LSPs.
3.8.2. Point-to-Point Unidirectional LSPs 3.8.2. Point-to-Point Unidirectional LSPs
Case 1 In this situation, either an in-band or out-of-band return Case 1 In this situation, either an in-band or out-of-band return
path may be used to deliver traffic from B back to A. path may be used to deliver traffic from B back to A.
In the in-band case there is in essence an associated In the in-band case there is in essence an associated
bidirectional LSP between A and B, and the discussion for bidirectional LSP between A and B, and the discussion for
such LSPs below applies. It is therefore recommended for such LSPs below applies. It is therefore recommended for
reasons of operational simplicity that point-to-point reasons of operational simplicity that point-to-point
skipping to change at page 32, line 35 skipping to change at page 32, line 36
return paths are also applicable. return paths are also applicable.
For Cases 2 and 3, the considerations are the same as those for For Cases 2 and 3, the considerations are the same as those for
point-to-point unidirectional LSPs. point-to-point unidirectional LSPs.
3.8.4. Point-to-Point Co-Routed Bidirectional LSPs 3.8.4. Point-to-Point Co-Routed Bidirectional LSPs
For all of Cases 1, 2, and 3, a natural in-band return path exists in For all of Cases 1, 2, and 3, a natural in-band return path exists in
the form of the LSP itself, and its use is typically preferred for the form of the LSP itself, and its use is typically preferred for
return traffic. Out-of-band return paths, however, are also return traffic. Out-of-band return paths, however, are also
applicable. applicable, primarily as an alternative means of delivery in case the
in-band return path has failed.
3.9. Control Plane 3.9. Control Plane
A distributed dynamic control plane may be used to enable dynamic A distributed dynamic control plane may be used to enable dynamic
service provisioning in an MPLS-TP network. Where the requirements service provisioning in an MPLS-TP network. Where the requirements
specified in [RFC5654] can be met, the MPLS Transport Profile uses specified in [RFC5654] can be met, the MPLS Transport Profile uses
existing standard control plane protocols for LSPs and PWs. existing standard control plane protocols for LSPs and PWs.
Note that a dynamic control plane is not required in an MPLS-TP Note that a dynamic control plane is not required in an MPLS-TP
network. See Section 3.11 for further details on statically network. See Section 3.11 for further details on statically
skipping to change at page 33, line 35 skipping to change at page 33, line 36
1) NMS may be centralised or distributed. Control plane is 1) NMS may be centralised or distributed. Control plane is
distributed. distributed.
2) 'Edge' functions refers to those functions present at 2) 'Edge' functions refers to those functions present at
the edge of a PSN domain, e.g. NSP or classification. the edge of a PSN domain, e.g. NSP or classification.
3) The control plane may be transported over the server 3) The control plane may be transported over the server
layer, an LSP or a G-ACh. layer, an LSP or a G-ACh.
Figure 13: MPLS-TP Control Plane Architecture Context Figure 13: MPLS-TP Control Plane Architecture Context
The MPLS-TP control plane is based on existing MPLS and PW control The MPLS-TP control plane is based on existing MPLS and PW control
plane protocols. MPLS-TP uses Generalized MPLS (GMPLS) signalling plane protocols. MPLS-TP uses Generalized MPLS (GMPLS) signaling
([RFC3945], [RFC3471], [RFC3473]) for LSPs and Targetted LDP (T-LDP) ([RFC3945], [RFC3471], [RFC3473]) for LSPs and Targeted LDP (T-LDP)
[RFC4447] [I-D.ietf-pwe3-segmented-pw][I-D.ietf-pwe3-dynamic-ms-pw] [RFC4447] [I-D.ietf-pwe3-segmented-pw][I-D.ietf-pwe3-dynamic-ms-pw]
for pseudowires. When T-LDP is used as the PW control protocol, for pseudowires.
MPLS-TP requires that it is capable of being carried over an out of
band signalling network or a signalling control channel [RFC5718]. MPLS-TP requires that any signaling be capable of being carried over
References to T-LDP in this document do not preclude the definition an out-of-band signaling network or a signaling control channel such
of alternative PW control protocols for use in MPLS-TP. as the one described in [RFC5718]. Note that while T-LDP signaling
is traditionally carried in-band in IP/MPLS networks, this does not
preclude its operation over out-of-band channels. References to
T-LDP in this document do not preclude the definition of alternative
PW control protocols for use in MPLS-TP.
PW control (and maintenance) takes place separately from LSP tunnel
signaling. The main coordination between LSP and PW control will
occur within the nodes that terminate PWs. The control planes for
PWs and LSPs may be used independently, and one may be employed
without the other. This translates into the four possible scenarios:
(1) no control plane is employed; (2) a control plane is used for
both LSPs and PWs; (3) a control plane is used for LSPs, but not PWs;
(4) a control plane is used for PWs, but not LSPs. The PW and LSP
control planes, collectively, must satisfy the MPLS-TP control plane
requirements reviewed in the MPLS-TP Control Plane Framework
[I-D.abfb-mpls-tp-control-plane-framework]. When client services are
provided directly via LSPs, all requirements must be satisfied by the
LSP control plane. When client services are provided via PWs, the PW
and LSP control planes operate in combination and some functions may
be satisfied via the PW control plane while others are provided to
PWs by the LSP control plane.
Note that if MPLS-TP is being used in a multi-layer network, a number Note that if MPLS-TP is being used in a multi-layer network, a number
of control protocol types and instances may be used. This is of control protocol types and instances may be used. This is
consistent with the MPLS architecture which permits each label in the consistent with the MPLS architecture which permits each label in the
label stack to be allocated and signalled by its own control label stack to be allocated and signaled by its own control protocol.
protocol.
The distributed MPLS-TP control plane may provide the following The distributed MPLS-TP control plane may provide the following
functions: functions:
o Signalling o Signaling
o Routing o Routing
o Traffic engineering and constraint-based path computation o Traffic engineering and constraint-based path computation
In a multi-domain environment, the MPLS-TP control plane supports In a multi-domain environment, the MPLS-TP control plane supports
different types of interfaces at domain boundaries or within the different types of interfaces at domain boundaries or within the
domains. These include the User-Network Interface (UNI), Internal domains. These include the User-Network Interface (UNI), Internal
Network Node Interface (I-NNI), and External Network Node Interface Network Node Interface (I-NNI), and External Network Node Interface
(E-NNI). Note that different policies may be defined that control (E-NNI). Note that different policies may be defined that control
skipping to change at page 34, line 48 skipping to change at page 35, line 23
A number of methods exist to support inter-domain operation of A number of methods exist to support inter-domain operation of
MPLS-TP, for example: MPLS-TP, for example:
o Inter-domain TE LSPs [RFC4216] o Inter-domain TE LSPs [RFC4216]
o Multi-segment Pseudowires [RFC5659] o Multi-segment Pseudowires [RFC5659]
o LSP stitching [RFC5150] o LSP stitching [RFC5150]
o back-to-back ACs [RFC5659] o back-to-back attachment circuits [RFC5659]
An important consideration in selecting an inter-domain connectivity An important consideration in selecting an inter-domain connectivity
mechanism is the degree of layer network isolation and types of OAM mechanism is the degree of layer network isolation and types of OAM
required by the operator. The selection of which technique to use in required by the operator. The selection of which technique to use in
a particular deployment scenario is outside the scope of this a particular deployment scenario is outside the scope of this
document. document.
3.11. Static Operation of LSPs and PWs 3.11. Static Operation of LSPs and PWs
A PW or LSP may be statically configured without the support of a A PW or LSP may be statically configured without the support of a
skipping to change at page 36, line 32 skipping to change at page 37, line 8
between a client and its server layer. between a client and its server layer.
o MPLS-TP recovery mechanisms can be data plane, control plane or o MPLS-TP recovery mechanisms can be data plane, control plane or
management plane based. management plane based.
o MPLS-TP supports revertive and non-revertive behaviour. o MPLS-TP supports revertive and non-revertive behaviour.
3.13. Path Segment Tunnels 3.13. Path Segment Tunnels
In order to monitor, protect and manage a portion of an LSP, a new In order to monitor, protect and manage a portion of an LSP, a new
architectural element is defined. This the Path Segment Tunnel architectural element is defined called the Path Segment Tunnel
(PST). A PST is an LSP defined and used for the purposes of OAM (PST). A PST is a hierarchical LSP [RFC3031] which is defined and
monitoring, protection or management of LSP segment or concatenated used for the purposes of OAM monitoring, protection or management of
LSP segments, and based on MPLS hierarchical nested LSP defined in LSP segments or concatenated LSP segments.
[RFC3031].
A PST is defined between the edges of the portion of the LSP that A PST is defined between the edges of the portion of the LSP that
needs to be monitored, protected or managed. Maintenance messages needs to be monitored, protected or managed. Maintenance messages
can be initiated at the edge of the PST and sent to the peer edge of can be initiated at the edge of the PST and sent to the peer edge of
the PST or to an intermediate point along the PST setting the TTL the PST or to an intermediate point along the PST by setting the TTL
value at the PST level accordingly. value at the PST level accordingly.
For example in Figure 14, three PSTs are configured to allow For example in Figure 14, three PSTs are configured to allow
monitoring, protection and management of the LSP concatenated monitoring, protection and management of the LSP concatenated
segments. One PST is defined between PE1 and PE2, the second between segments. One PST is defined between PE1 and PE2, the second between
PE2 and PE3 and a third PST is set up between PE3 and PE4. Each of PE2 and PE3 and a third PST is set up between PE3 and PE4. Each of
these three PSTs may be monitored, protected, or managed these three PSTs may be monitored, protected, or managed
independently. independently.
========================== End to End LSP ============================= ========================== End to End LSP =============================
|<--------- Carrier 1 --------->| |<----- Carrier 2 ----->| |<--------- Carrier 1 --------->| |<----- Carrier 2 ----->|
---| PE1 |---| P |---| P |---| PE2 |-------| PE3 |---| P |---| PE4 |--- ---| PE1 |---| P |---| P |---| PE2 |-------| PE3 |---| P |---| PE4 |---
|============= PST =============|==PST==|========= PST =========| |============= PST =============|==PST==|========= PST =========|
(Carrier 1) (Carrier 2) (Carrier 1) (Carrier 2)
Figure 14: PSTs in inter-carrier network Figure 14: PSTs in inter-carrier network
The end-to-end traffic of the LSP, including data-traffic and control The end-to-end traffic of the LSP, including data traffic and control
traffic (OAM, Protection Switching Control, management and signalling traffic (OAM, Protection Switching Control, management and signaling
messages) is tunneled within the PST by means of label stacking as messages) is tunneled within the PST by means of label stacking as
defined in [RFC3031]. defined in [RFC3031].
The mapping between an LSP and a PST can be 1:1, in which it is The mapping between an LSP and a PST can be 1:1, in which case it is
similar to the ITU-T Tandem Connection element [G.805]. The mapping similar to the ITU-T Tandem Connection element [G.805]. The mapping
can also be 1:N to allow aggregated monitoring, protection and can also be 1:N to allow aggregated monitoring, protection and
management of a set of LSP segments or concatenated LSP segments. management of a set of LSP segments or concatenated LSP segments.
Figure 15 shows a PST which is used to aggregate a set of Figure 15 shows a PST which is used to aggregate a set of
concatenated LSP segments for the LSP from PEx to PEt and the LSP concatenated LSP segments for the LSP from PEx to PEt and the LSP
from PEa to PEd. Note that such a construct is useful, for example, from PEa to PEd. Note that such a construct is useful, for example,
when the LSPs traverse a common portion of the network and they have when the LSPs traverse a common portion of the network and they have
the same Traffic Class. the same Traffic Class.
|PEx|--|PEy|-+ +-|PEz|--|PEt| |PEx|--|PEy|-+ +-|PEz|--|PEt|
skipping to change at page 37, line 46 skipping to change at page 38, line 20
| PE1 | | P | | P | | PE2 | | PE1 | | P | | P | | PE2 |
+--| |---| |---| |----| |--+ +--| |---| |---| |----| |--+
| +-----+ +---+ + P + +-----+ | | +-----+ +---+ + P + +-----+ |
| |============= PST ==============| | | |============= PST ==============| |
|PEa|--|PEb|-+ (Carrier 1) +-|PEc|--|PEd| |PEa|--|PEb|-+ (Carrier 1) +-|PEc|--|PEd|
Figure 15: PST for a Set of Concatenated LSP Segments Figure 15: PST for a Set of Concatenated LSP Segments
3.13.1. Provisioning of PST 3.13.1. Provisioning of PST
PSTs can be either provisioned statically or using control plane PSTs can be provisioned either statically or using control plane
signalling procedures. The make-before-break procedures which are signaling procedures. The make-before-break procedures which are
supported by MPLS allow the creation of a PST on existing LSPs in- supported by MPLS allow the creation of a PST on existing LSPs in-
service without traffic disruption. A PST can be defined service without traffic disruption. A PST can be defined
corresponding to one or more end-to-end tunneled LSPs. New end-to- corresponding to one or more end-to-end tunneled LSPs. New end-to-
end LSPs which are tunneled within the PST can be setup. Traffic of end LSPs which are tunneled within the PST can be set up. Traffic of
the existing LSPs is switched over to the new end-to-end tunneled the existing LSPs is switched over to the new end-to-end tunneled
LSPs. The old end-to-end LSPs can be tore down. LSPs. The old end-to-end LSPs can then be torn down.
3.14. Pseudowire Segment Tunnels 3.14. Pseudowire Segment Tunnels
Pseudowire segment tunnels are for further study. Pseudowire segment tunnels are for further study.
3.15. Network Management 3.15. Network Management
The network management architecture and requirements for MPLS-TP are The network management architecture and requirements for MPLS-TP are
specified in [I-D.ietf-mpls-tp-nm-framework] and specified in [I-D.ietf-mpls-tp-nm-framework] and
[I-D.ietf-mpls-tp-nm-req]. These derive from the generic [I-D.ietf-mpls-tp-nm-req]. These derive from the generic
skipping to change at page 40, line 47 skipping to change at page 41, line 21
This section contains a list of issues that must be resolved before This section contains a list of issues that must be resolved before
last call. last call.
o o
8. References 8. References
8.1. Normative References 8.1. Normative References
[G.7710] "ITU-T Recommendation [G.7710] "ITU-T Recommendation
G.7710/Y.1701 (07/07), G.7710/Y.1701 (07/07),
"Common equipment "Common equipment
management function management function
requirements"", 2005. requirements"", 2005.
[G.805] "ITU-T Recommendation G.805 [G.805] "ITU-T Recommendation
(11/95), "Generic G.805 (11/95), "Generic
Functional Architecture of Functional Architecture
Transport Networks"", of Transport Networks"",
November 1995. November 1995.
[RFC3031] Rosen, E., Viswanathan, A., [RFC3031] Rosen, E., Viswanathan,
and R. Callon, A., and R. Callon,
"Multiprotocol Label "Multiprotocol Label
Switching Architecture", Switching Architecture",
RFC 3031, January 2001. RFC 3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., [RFC3032] Rosen, E., Tappan, D.,
Fedorkow, G., Rekhter, Y., Fedorkow, G., Rekhter,
Farinacci, D., Li, T., and Y., Farinacci, D., Li,
A. Conta, "MPLS Label Stack T., and A. Conta, "MPLS
Encoding", RFC 3032, Label Stack Encoding",
January 2001. RFC 3032, January 2001.
[RFC3270] Le Faucheur, F., Wu, L., [RFC3270] Le Faucheur, F., Wu, L.,
Davie, B., Davari, S., Davie, B., Davari, S.,
Vaananen, P., Krishnan, R., Vaananen, P., Krishnan,
Cheval, P., and J. R., Cheval, P., and J.
Heinanen, "Multi-Protocol Heinanen, "Multi-Protocol
Label Switching (MPLS) Label Switching (MPLS)
Support of Differentiated Support of Differentiated
Services", RFC 3270, Services", RFC 3270,
May 2002. May 2002.
[RFC3471] Berger, L., "Generalized [RFC3471] Berger, L., "Generalized
Multi-Protocol Label Multi-Protocol Label
Switching (GMPLS) Signaling Switching (GMPLS)
Functional Description", Signaling Functional
RFC 3471, January 2003. Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., "Generalized [RFC3473] Berger, L., "Generalized
Multi-Protocol Label Multi-Protocol Label
Switching (GMPLS) Signaling Switching (GMPLS)
Resource ReserVation Signaling Resource
Protocol-Traffic ReserVation Protocol-
Engineering (RSVP-TE) Traffic Engineering
Extensions", RFC 3473, (RSVP-TE) Extensions",
January 2003. RFC 3473, January 2003.
[RFC3985] Bryant, S. and P. Pate, [RFC3985] Bryant, S. and P. Pate,
"Pseudo Wire Emulation "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Edge-to-Edge (PWE3)
Architecture", RFC 3985, Architecture", RFC 3985,
March 2005. March 2005.
[RFC4090] Pan, P., Swallow, G., and [RFC4090] Pan, P., Swallow, G., and
A. Atlas, "Fast Reroute A. Atlas, "Fast Reroute
Extensions to RSVP-TE for Extensions to RSVP-TE for
LSP Tunnels", RFC 4090, LSP Tunnels", RFC 4090,
May 2005. May 2005.
[RFC4385] Bryant, S., Swallow, G., [RFC4385] Bryant, S., Swallow, G.,
Martini, L., and D. Martini, L., and D.
McPherson, "Pseudowire McPherson, "Pseudowire
Emulation Edge-to-Edge Emulation Edge-to-Edge
(PWE3) Control Word for Use (PWE3) Control Word for
over an MPLS PSN", Use over an MPLS PSN",
RFC 4385, February 2006. RFC 4385, February 2006.
[RFC4447] Martini, L., Rosen, E., El- [RFC4447] Martini, L., Rosen, E.,
Aawar, N., Smith, T., and El-Aawar, N., Smith, T.,
G. Heron, "Pseudowire Setup and G. Heron, "Pseudowire
and Maintenance Using the Setup and Maintenance
Label Distribution Protocol Using the Label
(LDP)", RFC 4447, Distribution Protocol
April 2006. (LDP)", RFC 4447,
April 2006.
[RFC4872] Lang, J., Rekhter, Y., and [RFC4872] Lang, J., Rekhter, Y.,
D. Papadimitriou, "RSVP-TE and D. Papadimitriou,
Extensions in Support of "RSVP-TE Extensions in
End-to-End Generalized Support of End-to-End
Multi-Protocol Label Generalized Multi-
Switching (GMPLS) Protocol Label Switching
Recovery", RFC 4872, (GMPLS) Recovery",
May 2007. RFC 4872, May 2007.
[RFC5085] Nadeau, T. and C. [RFC5085] Nadeau, T. and C.
Pignataro, "Pseudowire Pignataro, "Pseudowire
Virtual Circuit Virtual Circuit
Connectivity Verification Connectivity Verification
(VCCV): A Control Channel (VCCV): A Control Channel
for Pseudowires", RFC 5085, for Pseudowires",
December 2007. RFC 5085, December 2007.
[RFC5462] Andersson, L. and R. Asati, [RFC5462] Andersson, L. and R.
"Multiprotocol Label Asati, "Multiprotocol
Switching (MPLS) Label Label Switching (MPLS)
Stack Entry: "EXP" Field Label Stack Entry: "EXP"
Renamed to "Traffic Class" Field Renamed to "Traffic
Field", RFC 5462, Class" Field", RFC 5462,
February 2009. February 2009.
[RFC5586] Bocci, M., Vigoureux, M., [RFC5586] Bocci, M., Vigoureux, M.,
and S. Bryant, "MPLS and S. Bryant, "MPLS
Generic Associated Generic Associated
Channel", RFC 5586, Channel", RFC 5586,
June 2009. June 2009.
8.2. Informative References 8.2. Informative References
[I-D.fang-mpls-tp-security-framework] Fang, L. and B. Niven- [I-D.abfb-mpls-tp-control-plane-framework] Andersson, L., Berger,
Jenkins, "Security L., Fang, L., Bitar, N.,
Framework for MPLS-TP", dra Takacs, A., and M.
ft-fang-mpls-tp-security- Vigoureux, "MPLS-TP
framework-00 (work in Control Plane Framework",
progress), July 2009. draft-abfb-mpls-tp-
control-plane-framework-
01 (work in progress),
July 2009.
[I-D.ietf-bfd-mpls] Aggarwal, R., Kompella, K., [I-D.fang-mpls-tp-security-framework] Fang, L. and B. Niven-
Nadeau, T., and G. Swallow, Jenkins, "Security
"BFD For MPLS LSPs", Framework for MPLS-TP", d
draft-ietf-bfd-mpls-07 raft-fang-mpls-tp-
(work in progress), security-framework-00
June 2008. (work in progress),
July 2009.
[I-D.ietf-l2vpn-vpms-frmwk-requirements] Kamite, Y., JOUNAY, F., [I-D.fbb-mpls-tp-data-plane] Frost, D., Bryant, S.,
Niven-Jenkins, B., and M. Bocci, "MPLS
Brungard, D., and L. Jin, Transport Profile Data
"Framework and Requirements Plane Architecture", draf
for Virtual Private t-fbb-mpls-tp-data-plane-
Multicast Service (VPMS)", 00 (work in progress),
draft-ietf-l2vpn-vpms- February 2010.
frmwk-requirements-02 (work
in progress), October 2009.
[I-D.ietf-mpls-tp-identifiers] Bocci, M. and G. Swallow, [I-D.ietf-bfd-mpls] Aggarwal, R., Kompella,
"MPLS-TP Identifiers", draf K., Nadeau, T., and G.
t-ietf-mpls-tp-identifiers- Swallow, "BFD For MPLS
00 (work in progress), LSPs",
November 2009. draft-ietf-bfd-mpls-07
(work in progress),
June 2008.
[I-D.ietf-mpls-tp-nm-framework] Mansfield, S., Gray, E., [I-D.ietf-l2vpn-vpms-frmwk-requirements] Kamite, Y., JOUNAY, F.,
and H. Lam, "MPLS-TP Niven-Jenkins, B.,
Network Management Brungard, D., and L. Jin,
Framework", draft-ietf- "Framework and
mpls-tp-nm-framework-04 Requirements for Virtual
(work in progress), Private Multicast Service
January 2010. (VPMS)", draft-ietf-
l2vpn-vpms-frmwk-
requirements-02 (work in
progress), October 2009.
[I-D.ietf-mpls-tp-nm-req] Mansfield, S. and K. Lam, [I-D.ietf-mpls-tp-identifiers] Bocci, M. and G. Swallow,
"MPLS TP Network Management "MPLS-TP Identifiers", dr
Requirements", draft-ietf- aft-ietf-mpls-tp-
mpls-tp-nm-req-06 (work in identifiers-00 (work in
progress), October 2009. progress), November 2009.
[I-D.ietf-mpls-tp-oam-framework] Allan, D., Busi, I., and B. [I-D.ietf-mpls-tp-nm-framework] Mansfield, S., Gray, E.,
Niven-Jenkins, "MPLS-TP OAM and H. Lam, "MPLS-TP
Framework", draft-ietf- Network Management
mpls-tp-oam-framework-04 Framework", draft-ietf-
(work in progress), mpls-tp-nm-framework-04
December 2009. (work in progress),
January 2010.
[I-D.ietf-mpls-tp-oam-requirements] Vigoureux, M., Ward, D., [I-D.ietf-mpls-tp-nm-req] Mansfield, S. and K. Lam,
and M. Betts, "Requirements "MPLS TP Network
for OAM in MPLS Transport Management Requirements",
Networks", draft-ietf-mpls- draft-ietf-mpls-tp-nm-
tp-oam-requirements-04 req-06 (work in
(work in progress), progress), October 2009.
December 2009.
[I-D.ietf-mpls-tp-survive-fwk] Sprecher, N. and A. Farrel, [I-D.ietf-mpls-tp-oam-framework] Allan, D., Busi, I., and
"Multiprotocol Label B. Niven-Jenkins,
Switching Transport Profile "MPLS-TP OAM Framework",
Survivability Framework", d draft-ietf-mpls-tp-oam-
raft-ietf-mpls-tp-survive- framework-04 (work in
fwk-03 (work in progress), progress), December 2009.
November 2009.
[I-D.ietf-pwe3-dynamic-ms-pw] Martini, L., Bocci, M., [I-D.ietf-mpls-tp-oam-requirements] Vigoureux, M., Ward, D.,
Balus, F., Bitar, N., Shah, and M. Betts,
H., Aissaoui, M., Rusmisel, "Requirements for OAM in
J., Serbest, Y., Malis, A., MPLS Transport Networks",
Metz, C., McDysan, D., draft-ietf-mpls-tp-oam-
Sugimoto, J., Duckett, M., requirements-04 (work in
Loomis, M., Doolan, P., progress), December 2009.
Pan, P., Pate, P., Radoaca,
V., Wada, Y., and Y. Seo,
"Dynamic Placement of Multi
Segment Pseudo Wires", draf
t-ietf-pwe3-dynamic-ms-pw-
10 (work in progress),
October 2009.
[I-D.ietf-pwe3-redundancy] Muley, P. and V. Place, [I-D.ietf-mpls-tp-survive-fwk] Sprecher, N. and A.
"Pseudowire (PW) Farrel, "Multiprotocol
Redundancy", draft-ietf- Label Switching Transport
pwe3-redundancy-02 (work in Profile Survivability
progress), October 2009. Framework", draft-ietf-
mpls-tp-survive-fwk-03
(work in progress),
November 2009.
[I-D.ietf-pwe3-segmented-pw] Martini, L., Nadeau, T., [I-D.ietf-pwe3-dynamic-ms-pw] Martini, L., Bocci, M.,
Metz, C., Duckett, M., Balus, F., Bitar, N.,
Bocci, M., Balus, F., and Shah, H., Aissaoui, M.,
M. Aissaoui, "Segmented Rusmisel, J., Serbest,
Pseudowire", draft-ietf- Y., Malis, A., Metz, C.,
pwe3-segmented-pw-13 (work McDysan, D., Sugimoto,
in progress), August 2009. J., Duckett, M., Loomis,
M., Doolan, P., Pan, P.,
Pate, P., Radoaca, V.,
Wada, Y., and Y. Seo,
"Dynamic Placement of
Multi Segment Pseudo
Wires", draft-ietf-pwe3-
dynamic-ms-pw-10 (work in
progress), October 2009.
[RFC3209] Awduche, D., Berger, L., [I-D.ietf-pwe3-redundancy] Muley, P. and V. Place,
Gan, D., Li, T., "Pseudowire (PW)
Srinivasan, V., and G. Redundancy", draft-ietf-
Swallow, "RSVP-TE: pwe3-redundancy-02 (work
Extensions to RSVP for LSP in progress),
Tunnels", RFC 3209, October 2009.
December 2001.
[RFC3411] Harrington, D., Presuhn, [I-D.ietf-pwe3-segmented-pw] Martini, L., Nadeau, T.,
R., and B. Wijnen, "An Metz, C., Duckett, M.,
Architecture for Describing Bocci, M., Balus, F., and
Simple Network Management M. Aissaoui, "Segmented
Protocol (SNMP) Management Pseudowire", draft-ietf-
Frameworks", STD 62, pwe3-segmented-pw-13
RFC 3411, December 2002. (work in progress),
August 2009.
[RFC3443] Agarwal, P. and B. Akyol, [RFC3209] Awduche, D., Berger, L.,
"Time To Live (TTL) Gan, D., Li, T.,
Processing in Multi- Srinivasan, V., and G.
Protocol Label Switching Swallow, "RSVP-TE:
(MPLS) Networks", RFC 3443, Extensions to RSVP for
January 2003. LSP Tunnels", RFC 3209,
December 2001.
[RFC3945] Mannie, E., "Generalized [RFC3411] Harrington, D., Presuhn,
Multi-Protocol Label R., and B. Wijnen, "An
Switching (GMPLS) Architecture for
Architecture", RFC 3945, Describing Simple Network
October 2004. Management Protocol
(SNMP) Management
Frameworks", STD 62,
RFC 3411, December 2002.
[RFC4216] Zhang, R. and J. Vasseur, [RFC3443] Agarwal, P. and B. Akyol,
"MPLS Inter-Autonomous "Time To Live (TTL)
System (AS) Traffic Processing in Multi-
Engineering (TE) Protocol Label Switching
Requirements", RFC 4216, (MPLS) Networks",
November 2005. RFC 3443, January 2003.
[RFC4364] Rosen, E. and Y. Rekhter, [RFC3945] Mannie, E., "Generalized
"BGP/MPLS IP Virtual Multi-Protocol Label
Private Networks (VPNs)", Switching (GMPLS)
RFC 4364, February 2006. Architecture", RFC 3945,
October 2004.
[RFC4377] Nadeau, T., Morrow, M., [RFC4216] Zhang, R. and J. Vasseur,
Swallow, G., Allan, D., and "MPLS Inter-Autonomous
S. Matsushima, "Operations System (AS) Traffic
and Management (OAM) Engineering (TE)
Requirements for Multi- Requirements", RFC 4216,
Protocol Label Switched November 2005.
(MPLS) Networks", RFC 4377,
February 2006.
[RFC4379] Kompella, K. and G. [RFC4364] Rosen, E. and Y. Rekhter,
Swallow, "Detecting Multi- "BGP/MPLS IP Virtual
Protocol Label Switched Private Networks (VPNs)",
(MPLS) Data Plane RFC 4364, February 2006.
Failures", RFC 4379,
February 2006.
[RFC4664] Andersson, L. and E. Rosen, [RFC4377] Nadeau, T., Morrow, M.,
"Framework for Layer 2 Swallow, G., Allan, D.,
Virtual Private Networks and S. Matsushima,
(L2VPNs)", RFC 4664, "Operations and
September 2006. Management (OAM)
Requirements for Multi-
Protocol Label Switched
(MPLS) Networks",
RFC 4377, February 2006.
[RFC4741] Enns, R., "NETCONF [RFC4379] Kompella, K. and G.
Configuration Protocol", Swallow, "Detecting
RFC 4741, December 2006. Multi-Protocol Label
Switched (MPLS) Data
Plane Failures",
RFC 4379, February 2006.
[RFC5150] Ayyangar, A., Kompella, K., [RFC4664] Andersson, L. and E.
Vasseur, JP., and A. Rosen, "Framework for
Farrel, "Label Switched Layer 2 Virtual Private
Path Stitching with Networks (L2VPNs)",
Generalized Multiprotocol RFC 4664, September 2006.
Label Switching Traffic
Engineering (GMPLS TE)",
RFC 5150, February 2008.
[RFC5254] Bitar, N., Bocci, M., and [RFC4741] Enns, R., "NETCONF
L. Martini, "Requirements Configuration Protocol",
for Multi-Segment RFC 4741, December 2006.
Pseudowire Emulation Edge-
to-Edge (PWE3)", RFC 5254,
October 2008.
[RFC5309] Shen, N. and A. Zinin, [RFC5150] Ayyangar, A., Kompella,
"Point-to-Point Operation K., Vasseur, JP., and A.
over LAN in Link State Farrel, "Label Switched
Routing Protocols", Path Stitching with
RFC 5309, October 2008. Generalized Multiprotocol
Label Switching Traffic
Engineering (GMPLS TE)",
RFC 5150, February 2008.
[RFC5331] Aggarwal, R., Rekhter, Y., [RFC5254] Bitar, N., Bocci, M., and
and E. Rosen, "MPLS L. Martini, "Requirements
Upstream Label Assignment for Multi-Segment
and Context-Specific Label Pseudowire Emulation
Space", RFC 5331, Edge-to-Edge (PWE3)",
August 2008. RFC 5254, October 2008.
[RFC5654] Niven-Jenkins, B., [RFC5309] Shen, N. and A. Zinin,
Brungard, D., Betts, M., "Point-to-Point Operation
Sprecher, N., and S. Ueno, over LAN in Link State
"Requirements of an MPLS Routing Protocols",
Transport Profile", RFC 5309, October 2008.
RFC 5654, September 2009.
[RFC5659] Bocci, M. and S. Bryant, [RFC5331] Aggarwal, R., Rekhter,
"An Architecture for Multi- Y., and E. Rosen, "MPLS
Segment Pseudowire Upstream Label Assignment
Emulation Edge-to-Edge", and Context-Specific
RFC 5659, October 2009. Label Space", RFC 5331,
August 2008.
[RFC5718] Beller, D. and A. Farrel, [RFC5654] Niven-Jenkins, B.,
"An In-Band Data Brungard, D., Betts, M.,
Communication Network For Sprecher, N., and S.
the MPLS Transport Ueno, "Requirements of an
Profile", RFC 5718, MPLS Transport Profile",
January 2010. RFC 5654, September 2009.
[RFC5659] Bocci, M. and S. Bryant,
"An Architecture for
Multi-Segment Pseudowire
Emulation Edge-to-Edge",
RFC 5659, October 2009.
[RFC5718] Beller, D. and A. Farrel,
"An In-Band Data
Communication Network For
the MPLS Transport
Profile", RFC 5718,
January 2010.
Authors' Addresses Authors' Addresses
Matthew Bocci (editor) Matthew Bocci (editor)
Alcatel-Lucent Alcatel-Lucent
Voyager Place, Shoppenhangers Road Voyager Place, Shoppenhangers Road
Maidenhead, Berks SL6 2PJ Maidenhead, Berks SL6 2PJ
United Kingdom United Kingdom
Phone: Phone:
skipping to change at page 47, line 42 skipping to change at page 49, line 4
Authors' Addresses Authors' Addresses
Matthew Bocci (editor) Matthew Bocci (editor)
Alcatel-Lucent Alcatel-Lucent
Voyager Place, Shoppenhangers Road Voyager Place, Shoppenhangers Road
Maidenhead, Berks SL6 2PJ Maidenhead, Berks SL6 2PJ
United Kingdom United Kingdom
Phone: Phone:
EMail: matthew.bocci@alcatel-lucent.com EMail: matthew.bocci@alcatel-lucent.com
Stewart Bryant (editor) Stewart Bryant (editor)
Cisco Systems Cisco Systems
250 Longwater Ave 250 Longwater Ave
Reading RG2 6GB Reading RG2 6GB
United Kingdom United Kingdom
Phone: Phone:
EMail: stbryant@cisco.com EMail: stbryant@cisco.com
Dan Frost
Dan Frost (editor)
Cisco Systems Cisco Systems
Phone: Phone:
Fax: Fax:
EMail: danfrost@cisco.com EMail: danfrost@cisco.com
URI: URI:
Lieven Levrau Lieven Levrau
Alcatel-Lucent Alcatel-Lucent
7-9, Avenue Morane Sulnier 7-9, Avenue Morane Sulnier
 End of changes. 100 change blocks. 
376 lines changed or deleted 430 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/