draft-ietf-mpls-tp-framework-07.txt   draft-ietf-mpls-tp-framework-08.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: June 25, 2010 D. Frost Expires: July 26, 2010 D. Frost
Cisco Systems Cisco Systems
L. Levrau L. Levrau
Alcatel-Lucent Alcatel-Lucent
L. Berger L. Berger
LabN LabN
December 22, 2009 January 22, 2010
A Framework for MPLS in Transport Networks A Framework for MPLS in Transport Networks
draft-ietf-mpls-tp-framework-07 draft-ietf-mpls-tp-framework-08
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 equivalents of traditional circuit- construction of packet-switched equivalents of traditional circuit-
switched carrier networks. It describes a common set of protocol switched carrier networks. It describes a common set of protocol
functions - the MPLS Transport Profile (MPLS-TP) - that supports the functions - the MPLS Transport Profile (MPLS-TP) - that supports the
operational models and capabilities typical of such networks, operational models and capabilities typical of such networks,
including signaled or explicitly provisioned bi-directional including signaled or explicitly provisioned bi-directional
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 June 25, 2010. This Internet-Draft will expire on July 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 29 skipping to change at page 3, line 29
1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 8
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
3.4.2. Pseudowire Adaptation . . . . . . . . . . . . . . . . 17 3.4.2. Pseudowire Adaptation . . . . . . . . . . . . . . . . 18
3.4.3. Network Layer Adaptation . . . . . . . . . . . . . . . 20 3.4.3. Network Layer Adaptation . . . . . . . . . . . . . . . 21
3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 24 3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 25
3.6. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 24 3.6. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 25
3.7. Operations, Administration and Maintenance (OAM) . . . . . 27 3.7. Operations, Administration and Maintenance (OAM) . . . . . 28
3.7.1. OAM Architecture . . . . . . . . . . . . . . . . . . . 28 3.7.1. OAM Architecture . . . . . . . . . . . . . . . . . . . 29
3.7.2. OAM Functions . . . . . . . . . . . . . . . . . . . . 31 3.7.2. OAM Functions . . . . . . . . . . . . . . . . . . . . 32
3.8. Control Plane . . . . . . . . . . . . . . . . . . . . . . 32 3.8. Control Plane . . . . . . . . . . . . . . . . . . . . . . 33
3.8.1. PW Control Plane . . . . . . . . . . . . . . . . . . . 34 3.8.1. PW Control Plane . . . . . . . . . . . . . . . . . . . 35
3.8.2. LSP Control Plane . . . . . . . . . . . . . . . . . . 34 3.8.2. LSP Control Plane . . . . . . . . . . . . . . . . . . 35
3.9. Static Operation of LSPs and PWs . . . . . . . . . . . . . 35 3.9. Static Operation of LSPs and PWs . . . . . . . . . . . . . 36
3.10. Survivability . . . . . . . . . . . . . . . . . . . . . . 35 3.10. Survivability . . . . . . . . . . . . . . . . . . . . . . 36
3.11. Network Management . . . . . . . . . . . . . . . . . . . . 37 3.11. Path Segment Tunnels . . . . . . . . . . . . . . . . . . . 38
4. Security Considerations . . . . . . . . . . . . . . . . . . . 38 3.11.1. Provisioning of PST . . . . . . . . . . . . . . . . . 39
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 3.12. Network Management . . . . . . . . . . . . . . . . . . . . 39
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 4. Security Considerations . . . . . . . . . . . . . . . . . . . 40
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 39 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
8.1. Normative References . . . . . . . . . . . . . . . . . . . 40 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.2. Informative References . . . . . . . . . . . . . . . . . . 42 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.1. Normative References . . . . . . . . . . . . . . . . . . . 42
8.2. Informative References . . . . . . . . . . . . . . . . . . 45
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
MPLS Transport Profile (MPLS-TP) for point-to-point paths. The MPLS Transport Profile (MPLS-TP) for point-to-point paths. The
skipping to change at page 16, line 34 skipping to change at page 16, line 34
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 specifies the architecture for two types of native This document describes the architecture for two types of native
service adaptation: service adaptation:
o A PW: PW Demultiplexer and PW encapsulation o A PW: PW Demultiplexer and PW encapsulation
o An MPLS Label o An MPLS Label
A PW can carry any emulated service defined by the IETF 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 client
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 network layer client supported by MPLS is allowed, for example an any client supported by [RFC3031] is allowed, for example a MPLS LSP,
MPLS LSP, PW, or IP. When the client adaptation is via an MPLS PW, or IP. When the client adaptation is via an MPLS label, the
label, the mechanisms described in Section 3.4.3 are used. 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
network boundary and the label context. It is not explicitly
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,
then the S bit of all the labels in the MPLS-TP label stack 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 S bit set in a label stack).
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
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
the client layer. Note that this best current practise differs
slightly from [RFC3032] which uses the S-bit to identify when MPLS
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
Figure 5. Figure 5.
PW-Based MPLS Labelled PW-Based MPLS Labelled
Services Services Services Services
|-----------------------------| |----------------------------|
Emulated PW LSP IP Emulated PW over LSP IP over LSP IP
Service Service
+------------+ +------------+
| PW Payload | | PW Payload |
+------------+ +------------+ +------------+ (CLIENTS) +------------+ +------------+ (CLIENTS)
| PW Payload | |PW Lbl(S=1) | | IP | |PW Lbl(S=1) | | IP |
~~~~~~~~~~~~~~~~~ +------------+ +------------+ +------------+
|PW Lbl (S=1)| | |LSP Lbl(S=0)| |LSP Lbl(S=1)| | IP |
+------------+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|LSP Lbl(S=0)| |LSP Lbl(S=0)| |LSP Lbl(S=0)| |LSP Lbl(S=1)|
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+ +------------+ +------------+
| PW Payload | |LSP Lbl(S=0)| |LSP Lbl(S=1)| | IP |
(MPLS-TP) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|PW Lbl (S=1)| |LSP Lbl(S=0)| |LSP Lbl(S=0)| |LSP Lbl(S=1)|
+------------+ +------------+ +------------+ +------------+
|LSP Lbl(S=0)|
+------------+ (MPLS-TP)
~~~~~~~~~~~ = Client - MPLS-TP layer boundary ~~~~~~~~~~~ = Client - MPLS-TP layer boundary
Note that in the PW over LSP case the client may omit its LSP Label if
penultimate hop popping has been agreed with its peer
Figure 5: MPLS-TP - Client Relationship Figure 5: MPLS-TP - Client Relationship
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. the client layer.
Note that this best current practise differs slightly from [RFC3032] Note that the label stacks shown above are divided between those
which uses the S-bit to identify when MPLS label processing stops and inside the MPLS-TP Network and those within the client network when
network layer processing starts. the client network is MPLS(-TP). They illustrate the smallest number
of labels possible. These label stacks could also include more
Note that the label stacks shown above are those inside MPLS-TP labels.
network. They illustrate the smallest number of labels possible.
These label stacks could also include more labels.
3.4.2. Pseudowire Adaptation 3.4.2. Pseudowire Adaptation
The architecture for an MPLS-TP client adaptation that uses PWs is The architecture for an MPLS-TP network that provides PW emulated
based on the MPLS [RFC3031] and pseudowire [RFC3985] architectures. services is based on the MPLS [RFC3031] and pseudowire [RFC3985]
If multi-segment pseudowires are used to provide a packet transport architectures. If multi-segment pseudowires are used to provide a
service, motivated by, for example, the requirements specified in packet transport service, motivated by, for example, the requirements
[RFC5254], then the MS-PW architecture [RFC5659] also applies. specified in [RFC5254], then the MS-PW architecture [RFC5659] also
applies.
Figure 6 shows the architecture for an MPLS-TP network using single- Figure 6 shows the architecture for an MPLS-TP network using single-
segment PWs. segment PWs.
|<--------------- Emulated Service ----------------->| |<--------------- Emulated Service ----------------->|
| | | |
| |<-------- Pseudowire -------->| | | |<-------- Pseudowire -------->| |
| | encapsulated packet | | | | encapsulated, packet | |
| | transport service | | | | transport service | |
| | | | | | | |
| | |<------ LSP ------->| | | | | |<------ LSP ------->| | |
| V V V V | | V V V V |
V AC +----+ +-----+ +----+ AC V V AC +----+ +-----+ +----+ AC V
+-----+ | | PE1|=======\ /========| PE2| | +-----+ +-----+ | | PE1|=======\ /========| PE2| | +-----+
| |----------|.......PW1.| \ / |............|----------| | | |----------|.......PW1.| \ / |............|----------| |
| CE1 | | | | | X | | | | | CE2 | | CE1 | | | | | X | | | | | CE2 |
| |----------|.......PW2.| / \ |............|----------| | | |----------|.......PW2.| / \ |............|----------| |
+-----+ ^ | | |=======/ \========| | | ^ +-----+ +-----+ ^ | | |=======/ \========| | | ^ +-----+
skipping to change at page 19, line 14 skipping to change at page 20, line 14
|<----------- Pseudowire encapsulated ------------->| |<----------- Pseudowire encapsulated ------------->|
| packet transport service | | packet transport service |
| | | |
| | | |
| | | |
AC | |<-------- LSP1 -------->| |<--LSP2-->| | AC AC | |<-------- LSP1 -------->| |<--LSP2-->| | AC
| V V V V V V | | V V V V V V |
| +----+ +-----+ +----+ +----+ | | +----+ +-----+ +----+ +----+ |
+---+ | |TPE1|===============\ /=====|SPE1|==========|TPE2| | +---+ +---+ | |TPE1|===============\ /=====|SPE1|==========|TPE2| | +---+
| |---|......PW.Seg't1... | \ / | ......X...PW.Seg't3.....|---| | | |---|......PW1-Seg1.... | \ / | ......X...PW1-Seg2......|---| |
|CE1| | | | | X | | | | | | |CE2| |CE1| | | | | X | | | | | | |CE2|
| |---|......PW.Seg't2... | / \ | ......X...PW.Seg't4.....|---| | | |---|......PW2-Seg1.... | / \ | ......X...PW2-Seg2......|---| |
+---+ | | |===============/ \=====| |==========| | | +---+ +---+ | | |===============/ \=====| |==========| | | +---+
^ +----+ ^ +-----+ +----+ ^ +----+ ^ ^ +----+ ^ +-----+ +----+ ^ +----+ ^
| | ^ | | | | ^ | |
| TE LSP | TE LSP | | TE LSP | TE LSP |
| P-router | | P-router |
| | | |
|<-------------------- Emulated Service ------------------->| |<-------------------- Emulated Service ------------------->|
PW1-segment1 and PW1-segment2 are segments of the same 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 domain of the MPLS-TP protocol stack including PWs The corresponding MPLS-TP protocol stacks including PWs are shown in
is shown in Figure 8. Figure 8. In this figure protocol the Transport Service Layer
[RFC5654] is identified by the PW demultiplexer (Demux) label and the
Transport Path Layer [RFC5654] is identified by the LSP Demux Label.
+-------------------+ +-------------------+ /===================\ /===================\
| Client Layer | | Client Layer | H OAM PDU H H OAM PDU H
/===================\ /===================\ /===================\ H-------------------H H-------------------H
H PW Encap H H PW OAM H H PW Encap H H GACh H H GACh H
H-------------------H H-------------------H /===================\ H-------------------H H-------------------H H-------------------H
H PW Demux (S=1) H H PW Demux (S=1) H H LSP OAM 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: Transport Service Layer = PW Demux Note: H(ighlighted) indicates the part of the protocol stack we are
Transport Path Layer = LSP Demux considering in this document.
Figure 8: MPLS-TP Layer Network using Pseudowires Figure 8: MPLS-TP Layer Network using Pseudowires
When providing a Virtual Private Wire Service (VPWS), Virtual Private
Local Area Network Service (VPLS), Virtual Private Multicast Service
(VPMS) or Internet Protocol Local Area Network Service (IPLS),
pseudowires must be used to carry the client service.
[Editors' note add references for the terms in this para].
PWs and their underlying labels may be configured or signaled. See PWs and their underlying labels may be configured or signaled. See
Section 3.9 for additional details related to configured service Section 3.9 for additional details related to configured service
types. See Section 3.8 for additional details related to signaled types. See Section 3.8 for additional details related to signaled
service types. service types.
3.4.2.1. Pseudowire Bases Services
When providing a Virtual Private Wire Service (VPWS) , Virtual
Private Local Area Network Service (VPLS), Virtual Private Multicast
Service (VPMS) or Internet Protocol Local Area Network Service (IPLS)
pseudowires must be used to carry the client service. VPWS, VLPS,
and IPLS are described in [RFC4664]. VPMS is described in
[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. Any MPLS-TP LSPs can be used to transport network layer clients. The
network layer protocol can be transported between service interfaces. network layer protocols supported by [RFC3031] and supported in
Examples of network layer protocols include IP, MPLS and MPLS-TP. [RFC3032] can be transported between service interfaces. Examples
Support for network layer clients follows the MPLS architecture for are shown in Figure 5 above. Support for network layer clients
support of network layer protocols as defined in [RFC3031] and follows the MPLS architecture for support of network layer protocols
supported in [RFC3032]. as defined in and supported in [RFC3032][RFC3031] and supported in
[RFC3032].
With network layer adaptation, the MPLS-TP domain provides a With network layer adaptation, the MPLS-TP domain provides either a
bidirectional point-to-point connection between two PEs in order to uni-directional or bidirectional point-to-point connection between
deliver a packet transport service to attached customer edge (CE) two PEs in order to deliver a packet transport service to attached
nodes. For example, a CE may be an IP, MPLS or MPLS-TP node. As customer edge (CE) nodes. For example, a CE may be an IP, MPLS or
shown in Figure 9, there is an attachment circuit between the CE node MPLS-TP node. As shown in Figure 9, there is an attachment circuit
on the left and its corresponding provider edge (PE) node which between the CE node on the left and its corresponding provider edge
provides the service interface, a bidirectional LSP across the (PE) node which provides the service interface, a bidirectional LSP
MPLS-TP network to the corresponding PE node on the right, and an across the MPLS-TP network to the corresponding PE node on the right,
attachment circuit between that PE node and the corresponding CE node and an attachment circuit between that PE node and the corresponding
for this service. CE node for this service.
The attachment circuits may be heterogeneous (e.g., any combination
of SDH, PPP, Frame Relay, etc.) and network layer protocol payloads
arrive at the service interface encapsulated in the Layer1/Layer2
encoding defined for that access link type. It should be noted that
the set of network layer protocols includes MPLS and hence MPLS
encoded packets with an MPLS label stack (the client MPLS stack), may
appear at the service interface.
|<------------- Client Network Layer-------------->| |<------------- Client Network Layer-------------->|
| | | |
| |<---- Pkt Xport Service --->| | |<---- Pkt Xport Service --->|
| | | | | | | |
| | |<-- PSN Tunnel -->| | | | | |<-- PSN Tunnel -->| | |
| V V V V | | V V V V |
V AC +----+ +---+ +----+ AC V V AC +----+ +---+ +----+ AC V
+-----+ | |PE1 | | | |PE2 | | +-----+ +-----+ | |PE1 | | | |PE2 | | +-----+
| | |LSP | | | | | | | | | | | |LSP | | | | | | | | |
skipping to change at page 21, line 28 skipping to change at page 22, line 42
| | Provider | ^ | Provider | | | | Provider | ^ | Provider | |
| | Edge | | | Edge | | | | Edge | | | Edge | |
Customer | 1 | P-router | 2 | Customer Customer | 1 | P-router | 2 | Customer
Edge 1 | TE TE | Edge 2 Edge 1 | TE TE | Edge 2
| LSP LSP | | LSP LSP |
| | | |
Native service Native service Native service Native service
Figure 9: MPLS-TP Architecture for Network Layer Clients Figure 9: MPLS-TP Architecture for Network Layer Clients
At the ingress service interface, the PE pushes one or more labels At the ingress service interface the client packets are received .
onto the ingress packets which are label switched over the transport The PE pushes one or more labels onto the client packets which are
network, and similarly the corresponding service interface at the then label switched over the transport network. Correspondingly the
egress PE pops any labels added by the MPLS-TP networks and delivers egress PE pops any labels added by the MPLS-TP networks and transmits
the packets to the attached CE. The attachment circuits may be the packet for delivery to the attached CE via the egress service
heterogeneous (e.g., any combination of SDH, PPP, Frame Relay, etc.)
and network layer protocol payloads arrive at the service interface
encapsulated in the Layer1/Layer2 encoding defined for that access
link type. It should be noted that the set of network layer
protocols includes MPLS and hence MPLS encoded packets with an MPLS
label stack (the client MPLS stack), may appear at the service
interface. interface.
+-------------------+ /===================\
| Client Layer | H OAM PDU H
/===================\ /===================\ +-------------------+ H-------------------H /===================\
H Encap Label H H SvcLSP OAM H | Client Layer | H GACh H H OAM PDU H
H-------------------H H-------------------H /===================\ /===================\ H-------------------H H-------------------H
H SvcLSP Demux H H SvcLSP Demux (S=1)H H LSP OAM H H Encap Label H H GAL (S=1) H H GACh H
H-------------------H H-------------------H H-------------------H
H SvcLSP Demux H H SvcLSP Demux (S=0)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 Service LSP OAM LSP OAM User Traffic Service LSP OAM LSP OAM
Note: Transport Service Layer = SvcLSP Demux
Transport Path Layer = LSP Demux
Note that the functions of the Encap label and the Service Label may be Note: H(ighlighted) indicates the part of the protocol stack we are
represented by a single label or omitted. Additionally, the S-bit will considering in this document.
always be zero when the client layer is MPLS labelled.
Figure 10: Domain of MPLS-TP Layer Network for IP and LSP Clients Figure 10: Domain of MPLS-TP Layer Network for IP and LSP Clients
In this figure the Transport Service Layer [RFC5654] is identified by
the Service LSP (SvcLSP) demultiplexer (Demux) label and the
Transport Path Layer [RFC5654] is identified by the LSP Demux Label.
Note that the functions of the Encapsulation label and the Service
Label shown above as SvcLSP Demux may be represented by a single
label stack entry. Additionally, the S-bit will always be zero when
the client layer is MPLS labelled.
Within the MPLS-TP transport network, the network layer protocols are Within the MPLS-TP transport network, the network layer protocols are
carried over the MPLS-TP network using a logically separate MPLS carried over the MPLS-TP network using a logically separate MPLS
label stack (the server stack). The server stack is entirely under label stack (the server stack). The server stack is entirely under
the control of the nodes within the MPLS-TP transport network and it the control of the nodes within the MPLS-TP transport network and it
is not visible outside that network. Figure 10 shows how a client is not visible outside that network. Figure 10 shows how a client
network protocol stack (which may be an MPLS label stack and payload) network protocol stack (which may be an MPLS label stack and payload)
is carried over a network layer client service over an MPLS-TP is carried over a network layer client service over an MPLS-TP
transport network. transport network.
A label per network layer protocol payload type that is to be A label per network layer protocol payload type that is to be
transported is required. Such labels are referred to as transported is required. When multiple protocol payload types are to
"Encapsulation Labels", one of which is shown in Figure 10. be carried over a single service a unique label stack entry must be
Encapsulation Label is either configured or signaled. present for each payload type. Such labels are referred to as
"Encapsulation Labels", one of which is shown in A label per network
layer protocol payload type that is to be transported is required.
Such labels are referred to as "Encapsulation Labels", one of which
is shown in Figure 10. Encapsulation Label is either configured or
signaled. Encapsulation Labels are either configured or signaled.
A Service Label should be used when a particular packet transport Both an Encapsulation Label and a Service Label should be present in
service is supporting more than one network layer protocol payload the label stack when a particular packet transport service is
type (and more than one Encapsulation Label is used). An example supporting more than one network layer protocol payload type. For
Service Label is shown in Figure 10. A Service Label may be omitted example, if both IP and MPLS are to be carried, as shown in Figure 9,
when only one encapsulation label is used in support of a particular then two Encapsulation Labels are mapped on to a common Service
service. For example, if only MPLS labelled packets are carried over Label.
a service, then a single Encapsulation Label would be used to provide
both payload type indication and service identification.
Alternatively, if both IP and MPLS is to be carried, as shown in
Figure 9, then two Encapsulation Labels could be mapped on to a
common Service Label.
Service labels are typically carried over an MPLS-TP edge-to-edge (or The Encapsulation Label may be omitted when the transport service is
transport path layer) LSP, which is also shown in Figure 10. The use supporting only one network layer protocol payload type. For
of an edge-to-edge LSP is recommended when more than one service example, if only MPLS labeled packets are carried over a service,
exists between two PEs. An edge-to-edge LSP may be omitted when only then the Service Label (stack entry) provides both the payload type
one service label is used in between two PEs. For example, if only indication and service identification.
one service is carried between two PEs then a single Service Label
could be used to provided both service indication and the MPLS-TP Service labels are typically carried over an MPLS-TP LSP edge-to-edge
edge-to-edge LSP. Alternatively, if multiple services exist between (or transport path layer). An MPLS-TP edge-to-edge LSP is
a pair of PEs then a per-client Service Label would be mapped on to a represented as an LSP Demux label as shown in Figure 10. An edge-to-
common MPLS-TP edge-to-edge LSP. edge LSP is commonly used when more than one service exists between
two PEs. The edge-to-edge LSP may be omitted when only one service
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
both the service indication and the MPLS-TP edge-to-edge LSP.
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
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
different layer 2 and layer 1 protocols on the two attachment different layer 2 and layer 1 protocols on the two attachment
circuits. circuits.
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.,
skipping to change at page 23, line 39 skipping to change at page 25, line 6
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 covered in this document. In some technologies the MAC address will
need to be configured (Examples for the Ethernet case include a need to be configured (Examples for the Ethernet case include a
configured unicast MAC address for the adjacent node, or even using 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 MAC
destination address for all packets sent over the service interface.) destination address for all packets sent over the service interface.)
Note that when the two CEs operating over the network layer transport Note that when two CEs, which peer with each other, operate over a
service are running a routing protocol such as IS-IS or OSPF some network layer transport service run a routing protocol such as IS-IS
care should be taken to configure the routing protocols to use point- or OSPF some care should be taken to configure the routing protocols
to-point adjacencies. The specifics of such configuration is outside to use point- to-point adjacencies .The specifics of such
the scope of this document. See [RFC5309] for additional details. configuration is outside the scope of this document. See [RFC5309]
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.9 for additional details related to or signaled . See Section 3.9 for additional details related to
configured service types. See Section 3.8 for additional details configured service types. See Section 3.8 for additional details
related to signaled service types. related to signaled service types.
3.5. Identifiers 3.5. Identifiers
Identifiers are used to uniquely distinguish entities in an MPLS-TP Identifiers are used to uniquely distinguish entities in an MPLS-TP
network. These include operators, nodes, LSPs, pseudowires, and network. These include operators, nodes, LSPs, pseudowires, and
their associated maintenance entities. their associated maintenance entities.
[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
skipping to change at page 37, line 5 skipping to change at page 38, line 5
o MPLS-TP recovery mechanisms support the coordination of protection o MPLS-TP recovery mechanisms support the coordination of protection
switching at multiple levels to prevent race conditions occurring switching at multiple levels to prevent race conditions occurring
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.11. Network Management 3.11. Path Segment Tunnels
In order to support the option to monitor, protect and manage a
portion of an LSP, a new architectural element is defined, Path
Segment Tunnel (PST). A Path Segment Tunnel is an LSP defined and
used for the purposes of OAM monitoring, protection or management of
LSP segment or concatenated LSP segments, and based on MPLS
hierarchical nested LSP defined in [RFC3031].
A PST is defined between the edges of the portion of the LSP that
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
the PST or to an intermediate point along the PST setting the TTL
value at the PST level accordingly.
For example in Figure 16, three PST are configured to allow
monitoring, protection and management of the LSP concatenated
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
these three PST may be monitored, protected, or managed
independently.
========================== End to End LSP =============================
|<--------- Carrier 1 --------->| |<----- Carrier 2 ----->|
---| PE1 |---| P |---| P |---| PE2 |-------| PE3 |---| P |---| PE4 |---
|============= PST =============|==PST==|========= PST =========|
(Carrier 1) (Carrier 2)
Figure 16: PSTs in inter-carrier network
The end-to-end traffic of the LSP, including data-traffic and control
traffic (OAM, PSC, management and signaling messages) is tunneled
within the PST by means of label stacking as defined in [RFC3031].
The mapping between an LSP and a PST can be 1:1 which is similar to
the IUT-T Tandem Connection element [G.805] which defines a sub layer
corresponding to a segment of a path and allows the monitoring of
that segment. The mapping can also be 1:N to allow scalable
monitoring, protection and management of a set of segments or
concatenated LSP segments traversing the same portion of a network.
Figure 2 shows a PST which is used to aggregate a set of concatenated
LSP segments of the following LSPs: LSP from PEx to PEt and LSP from
PEa to PEd. Note that such a construction may be useful if the LSPs
traverse via a common portion of the network and have the same
constrains, such as the same set of requirements for QoS, etc.
|PEx|--|PEy|-+ +-|PEz|--|PEt|
| |
| |<---------- Carrier 1 --------->| |
| +-----+ +---+ +---+ +-----+ |
+--| |---| |---| |----| |--+
| PE1 | | P | | P | | PE2 |
+--| |---| |---| |----| |--+
| +-----+ +---+ + P + +-----+ |
| |============= PST ==============| |
|PEa|--|PEb|-+ (Carrier 1) +-|PEc|--|PEd|
Figure 17: PST for a Set of Concatenated LSP Segments
3.11.1. Provisioning of PST
PSTs can be either provisioned statically or using control plane
signaling procedures. The make-before-break procedures which are
supported by MPLS allow the creation of a PST on existing LSPs in-
service without traffic disruption. A PST can be defined
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
the existing LSPs is switched over to the new end-to-end tunneled
LSPs. The old end-to-end LSPs can be tore down.
3.12. 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
specifications described in ITU-T G.7710/Y.1701 [G.7710] for specifications described in ITU-T G.7710/Y.1701 [G.7710] for
transport technologies. It also incorporates the OAM requirements transport technologies. It also incorporates the OAM requirements
for MPLS Networks [RFC4377] and MPLS-TP Networks for MPLS Networks [RFC4377] and MPLS-TP Networks
[I-D.ietf-mpls-tp-oam-requirements] and expands on those requirements [I-D.ietf-mpls-tp-oam-requirements] and expands on those requirements
to cover the modifications necessary for fault, configuration, to cover the modifications necessary for fault, configuration,
performance, and security in a transport network. performance, and security in a transport network.
skipping to change at page 39, line 18 skipping to change at page 41, line 45
o Italo Busi o Italo Busi
o John E Drake o John E Drake
o Hing-Kam Lam o Hing-Kam Lam
o Marc Lasserre o Marc Lasserre
o Vincenzo Sestito o Vincenzo Sestito
o Nurit Sprecher
o Martin Vigoureux o Martin Vigoureux
o Yaacov Weingarten
o The participants of ITU-T SG15 o The participants of ITU-T SG15
7. Open Issues 7. Open Issues
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 There is some text missing from the network layer clients section. o There is some text missing from the network layer clients section.
Text is invited covering the use of out of band signaling Text is invited covering the use of out of band signaling
associated with the AC. associated with the AC.
skipping to change at page 40, line 4 skipping to change at page 42, line 32
o Add a section clarify what options are used for interdomain o Add a section clarify what options are used for interdomain
operation e.g. inter-AS TE LSPs, MS-PW, LSP stitching, back-to- operation e.g. inter-AS TE LSPs, MS-PW, LSP stitching, back-to-
back ACs back ACs
o Text reduction for the OAM, survivability and NM sections. o Text reduction for the OAM, survivability and NM sections.
o Include summarised PST text o Include summarised PST text
8. References 8. References
8.1. Normative References 8.1. Normative References
[G.7710] "ITU-T Recommendation G.7710/ [G.7710] "ITU-T Recommendation
Y.1701 (07/07), "Common G.7710/Y.1701 (07/07),
equipment management function "Common equipment
requirements"", 2005. management function
requirements"", 2005.
[G.805] "ITU-T Recommendation G.805 [G.805] "ITU-T Recommendation G.805
(11/95), "Generic Functional (11/95), "Generic
Architecture of Transport Functional Architecture of
Networks"", November 1995. Transport Networks"",
November 1995.
[RFC3031] Rosen, E., Viswanathan, A., and [RFC3031] Rosen, E., Viswanathan, A.,
R. Callon, "Multiprotocol Label and R. Callon,
Switching Architecture", "Multiprotocol Label
RFC 3031, January 2001. Switching Architecture",
RFC 3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, [RFC3032] Rosen, E., Tappan, D.,
G., Rekhter, Y., Farinacci, D., Fedorkow, G., Rekhter, Y.,
Li, T., and A. Conta, "MPLS Farinacci, D., Li, T., and
Label Stack Encoding", RFC 3032, A. Conta, "MPLS Label Stack
January 2001. Encoding", RFC 3032,
January 2001.
[RFC3270] Le Faucheur, F., Wu, L., Davie, [RFC3270] Le Faucheur, F., Wu, L.,
B., Davari, S., Vaananen, P., Davie, B., Davari, S.,
Krishnan, R., Cheval, P., and J. Vaananen, P., Krishnan, R.,
Heinanen, "Multi-Protocol Label Cheval, P., and J.
Switching (MPLS) Support of Heinanen, "Multi-Protocol
Differentiated Services", Label Switching (MPLS)
RFC 3270, May 2002. Support of Differentiated
Services", RFC 3270,
May 2002.
[RFC3471] Berger, L., "Generalized Multi- [RFC3471] Berger, L., "Generalized
Protocol Label Switching (GMPLS) Multi-Protocol Label
Signaling Functional Switching (GMPLS) Signaling
Description", RFC 3471, Functional Description",
January 2003. RFC 3471, January 2003.
[RFC3473] Berger, L., "Generalized Multi- [RFC3473] Berger, L., "Generalized
Protocol Label Switching (GMPLS) Multi-Protocol Label
Signaling Resource ReserVation Switching (GMPLS) Signaling
Protocol-Traffic Engineering Resource ReserVation
(RSVP-TE) Extensions", RFC 3473, Protocol-Traffic
January 2003. Engineering (RSVP-TE)
Extensions", RFC 3473,
January 2003.
[RFC3985] Bryant, S. and P. Pate, "Pseudo [RFC3985] Bryant, S. and P. Pate,
Wire Emulation Edge-to-Edge "Pseudo Wire Emulation
(PWE3) Architecture", RFC 3985, Edge-to-Edge (PWE3)
March 2005. Architecture", RFC 3985,
March 2005.
[RFC4090] Pan, P., Swallow, G., and A. [RFC4090] Pan, P., Swallow, G., and
Atlas, "Fast Reroute Extensions A. Atlas, "Fast Reroute
to RSVP-TE for LSP Tunnels", Extensions to RSVP-TE for
RFC 4090, May 2005. LSP Tunnels", RFC 4090,
May 2005.
[RFC4203] Kompella, K. and Y. Rekhter, [RFC4203] Kompella, K. and Y.
"OSPF Extensions in Support of Rekhter, "OSPF Extensions
Generalized Multi-Protocol Label in Support of Generalized
Switching (GMPLS)", RFC 4203, Multi-Protocol Label
October 2005. Switching (GMPLS)",
RFC 4203, October 2005.
[RFC4385] Bryant, S., Swallow, G., [RFC4385] Bryant, S., Swallow, G.,
Martini, L., and D. McPherson, Martini, L., and D.
"Pseudowire Emulation Edge-to- McPherson, "Pseudowire
Edge (PWE3) Control Word for Use Emulation Edge-to-Edge
over an MPLS PSN", RFC 4385, (PWE3) Control Word for Use
February 2006. over an MPLS PSN",
RFC 4385, February 2006.
[RFC4447] Martini, L., Rosen, E., El- [RFC4447] Martini, L., Rosen, E., El-
Aawar, N., Smith, T., and G. Aawar, N., Smith, T., and
Heron, "Pseudowire Setup and G. Heron, "Pseudowire Setup
Maintenance Using the Label and Maintenance Using the
Distribution Protocol (LDP)", Label Distribution Protocol
RFC 4447, April 2006. (LDP)", RFC 4447,
April 2006.
[RFC4872] Lang, J., Rekhter, Y., and D. [RFC4872] Lang, J., Rekhter, Y., and
Papadimitriou, "RSVP-TE D. Papadimitriou, "RSVP-TE
Extensions in Support of End-to- Extensions in Support of
End Generalized Multi-Protocol End-to-End Generalized
Label Switching (GMPLS) Multi-Protocol Label
Recovery", RFC 4872, May 2007. Switching (GMPLS)
Recovery", RFC 4872,
May 2007.
[RFC5085] Nadeau, T. and C. Pignataro, [RFC5085] Nadeau, T. and C.
"Pseudowire Virtual Circuit Pignataro, "Pseudowire
Connectivity Verification Virtual Circuit
(VCCV): A Control Channel for Connectivity Verification
Pseudowires", RFC 5085, (VCCV): A Control Channel
December 2007. for Pseudowires", RFC 5085,
December 2007.
[RFC5307] Kompella, K. and Y. Rekhter, [RFC5307] Kompella, K. and Y.
"IS-IS Extensions in Support of Rekhter, "IS-IS Extensions
Generalized Multi-Protocol Label in Support of Generalized
Switching (GMPLS)", RFC 5307, Multi-Protocol Label
October 2008. Switching (GMPLS)",
RFC 5307, October 2008.
[RFC5462] Andersson, L. and R. Asati, [RFC5462] Andersson, L. and R. Asati,
"Multiprotocol Label Switching "Multiprotocol Label
(MPLS) Label Stack Entry: "EXP" Switching (MPLS) Label
Field Renamed to "Traffic Class" Stack Entry: "EXP" Field
Field", RFC 5462, February 2009. Renamed to "Traffic Class"
Field", RFC 5462,
February 2009.
[RFC5586] Bocci, M., Vigoureux, M., and S. [RFC5586] Bocci, M., Vigoureux, M.,
Bryant, "MPLS Generic Associated and S. Bryant, "MPLS
Channel", RFC 5586, June 2009. Generic Associated
Channel", RFC 5586,
June 2009.
8.2. Informative References 8.2. Informative References
[I-D.ietf-bfd-mpls] Aggarwal, R., Kompella, K., [I-D.ietf-bfd-mpls] Aggarwal, R., Kompella, K.,
Nadeau, T., and G. Swallow, "BFD Nadeau, T., and G. Swallow,
For MPLS LSPs", "BFD For MPLS LSPs",
draft-ietf-bfd-mpls-07 (work in draft-ietf-bfd-mpls-07
progress), June 2008. (work in progress),
June 2008.
[I-D.ietf-mpls-tp-identifiers] Bocci, M. and G. Swallow, [I-D.ietf-l2vpn-vpms-frmwk-requirements] Kamite, Y., JOUNAY, F.,
"MPLS-TP Identifiers", draft- Niven-Jenkins, B.,
ietf-mpls-tp-identifiers-00 Brungard, D., and L. Jin,
(work in progress), "Framework and Requirements
November 2009. for Virtual Private
Multicast Service (VPMS)",
draft-ietf-l2vpn-vpms-
frmwk-requirements-02 (work
in progress), October 2009.
[I-D.ietf-mpls-tp-nm-framework] Mansfield, S., Gray, E., and H. [I-D.ietf-mpls-tp-identifiers] Bocci, M. and G. Swallow,
Lam, "MPLS-TP Network Management "MPLS-TP Identifiers", draf
Framework", draft-ietf-mpls-tp- t-ietf-mpls-tp-identifiers-
nm-framework-02 (work in 00 (work in progress),
progress), November 2009. November 2009.
[I-D.ietf-mpls-tp-nm-req] Mansfield, S. and K. Lam, "MPLS [I-D.ietf-mpls-tp-nm-framework] Mansfield, S., Gray, E.,
TP Network Management and H. Lam, "MPLS-TP
Requirements", Network Management
draft-ietf-mpls-tp-nm-req-06 Framework", draft-ietf-
(work in progress), mpls-tp-nm-framework-04
October 2009. (work in progress),
January 2010.
[I-D.ietf-mpls-tp-oam-framework] Allan, D., Busi, I., and B. [I-D.ietf-mpls-tp-nm-req] Mansfield, S. and K. Lam,
Niven-Jenkins, "MPLS-TP OAM "MPLS TP Network Management
Framework", draft-ietf-mpls-tp- Requirements", draft-ietf-
oam-framework-04 (work in mpls-tp-nm-req-06 (work in
progress), December 2009. progress), October 2009.
[I-D.ietf-mpls-tp-oam-requirements] Vigoureux, M., Ward, D., and M. [I-D.ietf-mpls-tp-oam-framework] Allan, D., Busi, I., and B.
Betts, "Requirements for OAM in Niven-Jenkins, "MPLS-TP OAM
MPLS Transport Networks", draft- Framework", draft-ietf-
ietf-mpls-tp-oam-requirements-04 mpls-tp-oam-framework-04
(work in progress), (work in progress),
December 2009. December 2009.
[I-D.ietf-mpls-tp-survive-fwk] Sprecher, N. and A. Farrel, [I-D.ietf-mpls-tp-oam-requirements] Vigoureux, M., Ward, D.,
"Multiprotocol Label Switching and M. Betts, "Requirements
Transport Profile Survivability for OAM in MPLS Transport
Framework", draft-ietf-mpls-tp- Networks", draft-ietf-mpls-
survive-fwk-03 (work in tp-oam-requirements-04
progress), November 2009. (work in progress),
December 2009.
[I-D.ietf-pwe3-dynamic-ms-pw] Martini, L., Bocci, M., Balus, [I-D.ietf-mpls-tp-survive-fwk] Sprecher, N. and A. Farrel,
F., Bitar, N., Shah, H., "Multiprotocol Label
Aissaoui, M., Rusmisel, J., Switching Transport Profile
Serbest, Y., Malis, A., Metz, Survivability Framework", d
C., McDysan, D., Sugimoto, J., raft-ietf-mpls-tp-survive-
Duckett, M., Loomis, M., Doolan, fwk-03 (work in progress),
P., Pan, P., Pate, P., Radoaca, November 2009.
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.
[I-D.ietf-pwe3-redundancy] Muley, P. and V. Place, [I-D.ietf-pwe3-dynamic-ms-pw] Martini, L., Bocci, M.,
"Pseudowire (PW) Redundancy", Balus, F., Bitar, N., Shah,
draft-ietf-pwe3-redundancy-02 H., Aissaoui, M., Rusmisel,
(work in progress), J., Serbest, Y., Malis, A.,
October 2009. Metz, C., McDysan, D.,
Sugimoto, 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", draf
t-ietf-pwe3-dynamic-ms-pw-
10 (work in progress),
October 2009.
[I-D.ietf-pwe3-segmented-pw] Martini, L., Nadeau, T., Metz, [I-D.ietf-pwe3-redundancy] Muley, P. and V. Place,
C., Duckett, M., Bocci, M., "Pseudowire (PW)
Balus, F., and M. Aissaoui, Redundancy", draft-ietf-
"Segmented Pseudowire", pwe3-redundancy-02 (work in
draft-ietf-pwe3-segmented-pw-13 progress), October 2009.
(work in progress), August 2009.
[RFC3443] Agarwal, P. and B. Akyol, "Time [I-D.ietf-pwe3-segmented-pw] Martini, L., Nadeau, T.,
To Live (TTL) Processing in Metz, C., Duckett, M.,
Multi-Protocol Label Switching Bocci, M., Balus, F., and
(MPLS) Networks", RFC 3443, M. Aissaoui, "Segmented
January 2003. Pseudowire", draft-ietf-
pwe3-segmented-pw-13 (work
in progress), August 2009.
[RFC3945] Mannie, E., "Generalized Multi- [RFC3443] Agarwal, P. and B. Akyol,
Protocol Label Switching (GMPLS) "Time To Live (TTL)
Architecture", RFC 3945, Processing in Multi-
October 2004. Protocol Label Switching
(MPLS) Networks", RFC 3443,
January 2003.
[RFC4377] Nadeau, T., Morrow, M., Swallow, [RFC3945] Mannie, E., "Generalized
G., Allan, D., and S. Multi-Protocol Label
Matsushima, "Operations and Switching (GMPLS)
Management (OAM) Requirements Architecture", RFC 3945,
for Multi-Protocol Label October 2004.
Switched (MPLS) Networks",
RFC 4377, February 2006.
[RFC4379] Kompella, K. and G. Swallow, [RFC4377] Nadeau, T., Morrow, M.,
"Detecting Multi-Protocol Label Swallow, G., Allan, D., and
Switched (MPLS) Data Plane S. Matsushima, "Operations
Failures", RFC 4379, and Management (OAM)
February 2006. Requirements for Multi-
Protocol Label Switched
(MPLS) Networks", RFC 4377,
February 2006.
[RFC5146] Kumaki, K., "Interworking [RFC4379] Kompella, K. and G.
Requirements to Support Swallow, "Detecting Multi-
Operation of MPLS-TE over GMPLS Protocol Label Switched
Networks", RFC 5146, March 2008. (MPLS) Data Plane
Failures", RFC 4379,
February 2006.
[RFC5254] Bitar, N., Bocci, M., and L. [RFC4664] Andersson, L. and E. Rosen,
Martini, "Requirements for "Framework for Layer 2
Multi-Segment Pseudowire Virtual Private Networks
Emulation Edge-to-Edge (PWE3)", (L2VPNs)", RFC 4664,
RFC 5254, October 2008. September 2006.
[RFC5309] Shen, N. and A. Zinin, "Point- [RFC5146] Kumaki, K., "Interworking
to-Point Operation over LAN in Requirements to Support
Link State Routing Protocols", Operation of MPLS-TE over
RFC 5309, October 2008. GMPLS Networks", RFC 5146,
March 2008.
[RFC5331] Aggarwal, R., Rekhter, Y., and [RFC5254] Bitar, N., Bocci, M., and
E. Rosen, "MPLS Upstream Label L. Martini, "Requirements
Assignment and Context-Specific for Multi-Segment
Label Space", RFC 5331, Pseudowire Emulation Edge-
August 2008. to-Edge (PWE3)", RFC 5254,
October 2008.
[RFC5654] Niven-Jenkins, B., Brungard, D., [RFC5309] Shen, N. and A. Zinin,
Betts, M., Sprecher, N., and S. "Point-to-Point Operation
Ueno, "Requirements of an MPLS over LAN in Link State
Transport Profile", RFC 5654, Routing Protocols",
September 2009. RFC 5309, October 2008.
[RFC5659] Bocci, M. and S. Bryant, "An [RFC5331] Aggarwal, R., Rekhter, Y.,
Architecture for Multi-Segment and E. Rosen, "MPLS
Pseudowire Emulation Edge-to- Upstream Label Assignment
Edge", RFC 5659, October 2009. and Context-Specific Label
Space", RFC 5331,
August 2008.
[RFC5654] Niven-Jenkins, B.,
Brungard, D., Betts, M.,
Sprecher, N., and S. Ueno,
"Requirements of an MPLS
Transport Profile",
RFC 5654, September 2009.
[RFC5659] Bocci, M. and S. Bryant,
"An Architecture for Multi-
Segment Pseudowire
Emulation Edge-to-Edge",
RFC 5659, October 2009.
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:
 End of changes. 79 change blocks. 
339 lines changed or deleted 516 lines changed or added

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