draft-ietf-mpls-tp-framework-04.txt   draft-ietf-mpls-tp-framework-05.txt 
MPLS Working Group M. Bocci, Ed. MPLS Working Group M. Bocci, Ed.
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Standards Track S. Bryant, Ed. Intended status: Standards Track S. Bryant, Ed.
Expires: March 15, 2010 Cisco Systems Expires: March 29, 2010 D. Frost
Cisco Systems
L. Levrau L. Levrau
Alcatel-Lucent Alcatel-Lucent
D. Frost September 25, 2009
Cisco Systems
September 11, 2009
A Framework for MPLS in Transport Networks A Framework for MPLS in Transport Networks
draft-ietf-mpls-tp-framework-04 draft-ietf-mpls-tp-framework-05
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 36
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 March 15, 2010. This Internet-Draft will expire on March 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 10 skipping to change at page 3, line 10
Although this document is not a protocol specification, these key Although this document is not a protocol specification, these key
words are to be interpreted as instructions to the protocol designers words are to be interpreted as instructions to the protocol designers
producing solutions that satisfy the architectural concepts set out producing solutions that satisfy the architectural concepts set out
in this document. in this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation and Background . . . . . . . . . . . . . . . . 4 1.1. Motivation and Background . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1. MPLS Transport Profile. . . . . . . . . . . . . . . . 6 1.3.1. MPLS Transport Profile. . . . . . . . . . . . . . . . 6
1.3.2. MPLS-TP Label Switched Path . . . . . . . . . . . . . 6 1.3.2. MPLS-TP Section . . . . . . . . . . . . . . . . . . . 6
1.3.3. MPLS-TP Label Switching Router and Label Edge 1.3.3. MPLS-TP Label Switched Path . . . . . . . . . . . . . 6
Router . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3.4. MPLS-TP Label Switching Router (LSR) and Label
1.3.4. Additional Definitions and Terminology . . . . . . . . 7 Edge Router (LER) . . . . . . . . . . . . . . . . . . 6
1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 1.3.5. MPLS-TP Customer Edge (CE) . . . . . . . . . . . . . . 7
1.3.6. Additional Definitions and Terminology . . . . . . . . 7
1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 7
2. Introduction to Requirements . . . . . . . . . . . . . . . . . 8 2. Introduction to Requirements . . . . . . . . . . . . . . . . . 8
3. Transport Profile Overview . . . . . . . . . . . . . . . . . . 9 3. Transport Profile Overview . . . . . . . . . . . . . . . . . . 8
3.1. Packet Transport Services . . . . . . . . . . . . . . . . 9 3.1. Packet Transport Services . . . . . . . . . . . . . . . . 8
3.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. MPLS-TP Forwarding Domain . . . . . . . . . . . . . . . . 15 3.2.1. MPLS-TP Adaptation Functions . . . . . . . . . . . . . 10
3.4. MPLS-TP LSP Clients . . . . . . . . . . . . . . . . . . . 17 3.2.2. MPLS-TP Forwarding Functions . . . . . . . . . . . . . 11
3.4.1. Network Layer Transport Service . . . . . . . . . . . 17 3.3. MPLS-TP LSP Clients . . . . . . . . . . . . . . . . . . . 12
3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 21 3.3.1. Pseudowires . . . . . . . . . . . . . . . . . . . . . 12
3.6. Operations, Administration and Maintenance (OAM) . . . . . 22 3.3.2. Network Layer Clients . . . . . . . . . . . . . . . . 15
3.7. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 26 3.4. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 20
3.8. Control Plane . . . . . . . . . . . . . . . . . . . . . . 29 3.5. Operations, Administration and Maintenance (OAM) . . . . . 21
3.8.1. PW Control Plane . . . . . . . . . . . . . . . . . . . 31 3.6. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 25
3.8.2. LSP Control Plane . . . . . . . . . . . . . . . . . . 31 3.7. Control Plane . . . . . . . . . . . . . . . . . . . . . . 28
3.9. Static Operation of LSPs and PWs . . . . . . . . . . . . . 32 3.7.1. PW Control Plane . . . . . . . . . . . . . . . . . . . 30
3.10. Survivability . . . . . . . . . . . . . . . . . . . . . . 32 3.7.2. LSP Control Plane . . . . . . . . . . . . . . . . . . 30
3.11. Network Management . . . . . . . . . . . . . . . . . . . . 33 3.8. Static Operation of LSPs and PWs . . . . . . . . . . . . . 31
4. Security Considerations . . . . . . . . . . . . . . . . . . . 34 3.9. Survivability . . . . . . . . . . . . . . . . . . . . . . 31
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 3.10. Network Management . . . . . . . . . . . . . . . . . . . . 32
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 4. Security Considerations . . . . . . . . . . . . . . . . . . . 33
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
7.1. Normative References . . . . . . . . . . . . . . . . . . . 35 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
7.2. Informative References . . . . . . . . . . . . . . . . . . 38 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.1. Normative References . . . . . . . . . . . . . . . . . . . 34
7.2. Informative References . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
1.1. Motivation and Background 1.1. Motivation and Background
This document describes a framework for a Multiprotocol Label This document describes a framework for a Multiprotocol Label
Switching Transport Profile (MPLS-TP). It presents the architectural Switching Transport Profile (MPLS-TP). It presents the architectural
framework for MPLS-TP, defining those elements of MPLS applicable to framework for MPLS-TP, defining those elements of MPLS applicable to
supporting the requirements in [I-D.ietf-mpls-tp-requirements] and supporting the requirements in [RFC5654] and what new protocol
what new protocol elements are required. elements are required.
Historically the optical transport infrastructure (Synchronous Historically the optical transport infrastructure (Synchronous
Optical Networking (SONET)/Synchronous Digital Hierarchy (SDH), Optical Networking (SONET)/Synchronous Digital Hierarchy (SDH),
Optical Transport Network (OTN)) has provided carriers with a high Optical Transport Network (OTN)) has provided carriers with a high
benchmark for reliability and operational simplicity. To achieve benchmark for reliability and operational simplicity. To achieve
this transport technologies have been designed with specific this transport technologies have been designed with specific
characteristics : characteristics :
o Strictly connection-oriented connectivity, which may be long-lived o Strictly connection-oriented connectivity, which may be long-lived
and may be provisioned manually or by network management. and may be provisioned manually or by network management.
skipping to change at page 5, line 12 skipping to change at page 5, line 12
similar degree of predictability to that found in existing similar degree of predictability to that found in existing
transport networks. transport networks.
In order to achieve these objectives, there is a need to create a In order to achieve these objectives, there is a need to create a
common set of new functions that are applicable to both MPLS networks common set of new functions that are applicable to both MPLS networks
in general, and those belonging to the MPLS-TP profile. in general, and those belonging to the MPLS-TP profile.
MPLS-TP therefore defines a profile of MPLS targeted at transport MPLS-TP therefore defines a profile of MPLS targeted at transport
applications and networks. This profile specifies the specific MPLS applications and networks. This profile specifies the specific MPLS
characteristics and extensions required to meet transport characteristics and extensions required to meet transport
requirements. An equipment conforming to MPLS-TP MUST support this requirements.
profile. An MPLS-TP conformant equipment MAY support additional MPLS
features. A carrier may deploy some of those additional features in
the transport layer of their network if they find them to be
beneficial.
1.2. Scope 1.2. Scope
This document describes a framework for a Transport Profile of This document describes an architectural framework for the
Multiprotocol Label Switching (MPLS-TP). It presents the application of MPLS to transport networks. It specifies the common
architectural framework for MPLS-TP, defining those elements of MPLS set of protocol functions that meet the requirements in [RFC5654],
applicable to supporting the requirements in and that together constitute the MPLS Transport Profile (MPLS-TP).
[I-D.ietf-mpls-tp-requirements] and what new protocol elements are
required.
1.3. Terminology 1.3. Terminology
Term Definition Term Definition
---------------- ------------------------------------------ ---------------- ------------------------------------------
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
skipping to change at page 6, line 37 skipping to change at page 6, line 8
CM Configuration Management CM Configuration Management
PM Performance Management PM Performance Management
LSR Label Switch Router. LSR Label Switch Router.
MPLS-TP PE MPLS-TP Provider Edge MPLS-TP PE MPLS-TP Provider Edge
MPLS-TP P Router An MPLS-TP Provider (P) router MPLS-TP P Router An MPLS-TP Provider (P) router
PW Pseudowire PW Pseudowire
1.3.1. MPLS Transport Profile. 1.3.1. MPLS Transport Profile.
The MPLS Transport Profile (MPLS-TP) is the set of MPLS functions The MPLS Transport Profile (MPLS-TP) is the set of MPLS functions
that meet the requirements in [I-D.ietf-mpls-tp-requirements]. Note that meet the requirements in [RFC5654]. Note that MPLS is defined
that MPLS is defined to include any present and future MPLS to include any present and future MPLS capability specified by the
capability specified by the IETF, include those capabilities IETF, include those capabilities specifically added to support the
specifically added to support the transport network requirement transport network requirement [RFC5654].
[I-D.ietf-mpls-tp-requirements].
1.3.2. MPLS-TP Label Switched Path 1.3.2. MPLS-TP Section
An MPLS-TP Section is defined in Secion 1.1.2 of [RFC5654].
1.3.3. MPLS-TP Label Switched Path
An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that uses a An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that uses a
subset of the capabilities of an MPLS LSP in order to meet the subset of the capabilities of an MPLS LSP in order to meet the
requirements of an MPLS transport network as set out in requirements of an MPLS transport network as set out in [RFC5654].
[I-D.ietf-mpls-tp-requirements]. The characteristics of an MPLS-TP The characteristics of an MPLS-TP LSP are primarily that it:
LSP are primarily that it:
1. Uses a subset of the MPLS OAM tools defined as described in 1. Uses a subset of the MPLS OAM tools defined as described in
[I-D.ietf-mpls-tp-oam-framework]. [I-D.ietf-mpls-tp-oam-framework].
2. Supports only 1+1, 1:1, and 1:N protection functions. 2. Supports only 1+1, 1:1, and 1:N protection functions.
3. Is traffic engineered. 3. Is traffic engineered.
4. Is established and maintained using GMPLS protocols when a 4. Is established and maintained using GMPLS protocols when a
control plane is used. control plane is used.
5. LSPs can only be point to point or point to multipoint, i.e. the 5. LSPs can only be point to point or point to multipoint, i.e. the
merging of LSPs is not permitted. merging of LSPs is not permitted.
Note that an MPLS LSP is defined to include any present and future Note that an MPLS LSP is defined to include any present and future
MPLS capability include those specifically added to support the MPLS capability include those specifically added to support the
transport network requrements. transport network requrements.
1.3.3. MPLS-TP Label Switching Router and Label Edge Router 1.3.4. MPLS-TP Label Switching Router (LSR) and Label Edge Router (LER)
An MPLS-TP Label Switching Router (MPLS-TP LSR) is either an MPLS-TP An MPLS-TP Label Switching Router (MPLS-TP LSR) is either an MPLS-TP
Provider Edge (MPLS-TP PE) or an MPLS-TP Provider (MPLS-TP P Router) Provider Edge (MPLS-TP PE) or an MPLS-TP Provider (MPLS-TP P Router)
router as defined below. The terms MPLS-TP PE and MPLS-TP P router router as defined below. The terms MPLS-TP PE and MPLS-TP P router
describe functions and specific node may undertake both roles. Note describe functions and specific node may undertake both roles. Note
that the use of the term "router" in this context is historic and that the use of the term "router" in this context is historic and
neither requires nor precludes the ability to perform IP forwarding. neither requires nor precludes the ability to perform IP forwarding.
1.3.3.1. MPLS-TP Provider Edge Router 1.3.4.1. MPLS-TP Provider Edge Router (PE)
An MPLS-TP Provider Edge is an MPLS-TP LSR that adapts client traffic An MPLS-TP Provider Edge Router is an MPLS-TP LSR that adapts client
and encapsulate it to be carried over an MPLS-TP LSP. Encapsulation traffic and encapsulates it to be carried over an MPLS-TP LSP.
may be as simple as pushing a label, or it may require the use of a Encapsulation may be as simple as pushing a label, or it may require
pseudowire. An MPLS-TP PE exists at the interface between a pair of the use of a pseudowire. An MPLS-TP PE exists at the interface
layer networks. between a pair of layer networks.
A layer network is defined in [I-D.ietf-mpls-tp-rosetta-stone]. A layer network is defined in [I-D.ietf-mpls-tp-rosetta-stone].
1.3.3.2. MPLS-TP Provider Router 1.3.4.2. MPLS-TP Provider Router (P)
An MPLS-TP Provider router is an MPLS-TP LSR that does not provide An MPLS-TP Provider router is an MPLS-TP LSR that does not provide
MPLS-TP PE functionality. An MPLS-TP P router switches LSPs which MPLS-TP PE functionality. An MPLS-TP P router switches LSPs which
carry client traffic, but do not adapt the client traffic and carry client traffic, but do not adapt the client traffic and
encapsulate it to be carried over an MPLS-TP LSP. encapsulate it to be carried over an MPLS-TP LSP.
1.3.4. Additional Definitions and Terminology 1.3.5. MPLS-TP Customer Edge (CE)
An MPLS-TP Customer Edge is the client function sourcing or sinking
client 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 a
single point to point or point to multi-point link. These clients
have no knowledge of the presence of the interveining MPLS-TP
network.
1.3.6. Additional Definitions and Terminology
Detailed definitions and additional terminology may be found in . Detailed definitions and additional terminology may be found in .
[I-D.ietf-mpls-tp-requirements]. [RFC5654].
1.4. Applicability 1.4. Applicability
MPLS-TP can be used to construct a packet transport networks and is MPLS-TP can be used to construct a packet transport networks and is
therefore applicable in any packet transport network application. It therefore applicable in any packet transport network application. It
is also as an alternative architecture for subsets of a packet is also as an alternative architecture for subsets of a packet
network where the transport network model is deemed attractive. network where the transport network model is deemed attractive.
These two modes can be considered vertical and horizontal These two modes can be considered vertical and horizontal
applicability models. In the first case an MPLS-TP network is viewed applicability models. In the first case an MPLS-TP network is viewed
as below the IP packet network i.e. provides the data link layer as below an IP packet network i.e. provides the data link layer
service for an IP network; in the second mode it is viewed as part of service for an IP network; in the second case, MPLS-TP acts as an
the IP/MPLS network and peers/interconnects directly to it. These aggregation for client traffic into an IP-based MPLS network, or a
transit for client traffic between IP-based MPLS networks. These
models are not mutually exclusive. models are not mutually exclusive.
2. Introduction to Requirements 2. Introduction to Requirements
The requirements for MPLS-TP are specified in The requirements for MPLS-TP are specified in [RFC5654],
[I-D.ietf-mpls-tp-requirements], [I-D.ietf-mpls-tp-oam-requirements], [I-D.ietf-mpls-tp-oam-requirements], and [I-D.ietf-mpls-tp-nm-req].
and [I-D.ietf-mpls-tp-nm-req]. This section provides a brief This section provides a brief reminder to guide the reader. It is
reminder to guide the reader. It is not intended as a substitute for not intended as a substitute for these documents.
these documents.
MPLS-TP MUST NOT modify the MPLS forwarding architecture and MUST be MPLS-TP MUST NOT modify the MPLS forwarding architecture and MUST be
based on existing pseudowire and LSP constructs. Any new mechanisms based on existing pseudowire and LSP constructs. Any new mechanisms
and capabilities added to support transport networks and packet and capabilities added to support transport networks and packet
transport services must be able to inter-operate with existing MPLS transport services must be able to inter-operate with existing MPLS
and pseudowire control and forwarding planes. and pseudowire control and forwarding planes.
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. Point MUST be possible to construct congruent Bi-directional LSPs. Point
to multipoint LSPs are unidirectional. to multipoint LSPs are unidirectional.
skipping to change at page 9, line 12 skipping to change at page 8, line 46
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. Transport Profile Overview 3. Transport Profile Overview
3.1. Packet Transport Services 3.1. Packet Transport Services
One objective of MPLS-TP is to enable MPLS networks to provide packet One objective of MPLS-TP is to enable MPLS networks to provide packet
transport services with a similar degree of predictability to that transport services with a similar degree of predictability to that
found in existing transport networks. Such packet transport services found in existing transport networks. Such packet transport services
inherit a number of characteristics, defined in inherit a number of characteristics, defined in [RFC5654].
[I-D.ietf-mpls-tp-requirements].
o In an environment where an MPLS-TP layer network is supporting a o In an environment where an MPLS-TP layer network is supporting a
client layer network, and the MPLS-TP layer network is supported client layer network, and the MPLS-TP layer network is supported
by a server layer network then operation of the MPLS-TP layer by a server layer network then operation of the MPLS-TP layer
network MUST be possible without any dependencies on the server or network MUST be possible without any dependencies on the server or
client layer network. client layer network.
o The service provided by the MPLS-TP network to the client is o The service provided by the MPLS-TP network to the client is
guaranteed not to fall below the agreed level regardless of other guaranteed not to fall below the agreed level regardless of other
client activity. client activity.
skipping to change at page 10, line 31 skipping to change at page 10, line 12
supported by MPLS. MPLS-TP solutions are primarily intended for supported by MPLS. MPLS-TP solutions are primarily intended for
packet transport applications. These can be deployed using a profile packet transport applications. These can be deployed using a profile
of MPLS that is strictly connection oriented and does not rely on IP of MPLS that is strictly connection oriented and does not rely on IP
forwarding or routing (shown on the right hand side of the figure), forwarding or routing (shown on the right hand side of the figure),
or in conjunction with an MPLS network that does use IP forwarding or in conjunction with an MPLS network that does use IP forwarding
and that supports a broader range of IP services. This is the multi- and that supports a broader range of IP services. This is the multi-
service solution in the centre of the figure. service solution in the centre of the figure.
3.2. Architecture 3.2. Architecture
[Editors' Note Section 3.2 needs to generalized to include the MPLS-TP comprises the following
architecture when PWs are not being transported and the client is IP,
MPLS or a network layer service over MPLS-TP LSPs as described in
section 3.4]
EDITOR'S NOTE Comment received from Dan Frost that we need to o Sections, point to point and point to multipoint LSPs and PWs that
address: provide a packet transport service for a client network.
======== o Proactive and on demand Operations Administration and Maintenance
(OAM) functions to monitor and diagnose the MPLS-TP network. e.g.
connectivity check, connectivity verification, and performance
monitoring.
- Sections 3.2 (Architecture) - 3.4 (MPLS-TP Forwarding Domain) o Optional control planes for LSPs and PWs, as well as static
configuration.
The organisation of these sections is confusing. It appears as if o Path protection mechanisms to ensure that the packet transport
the current content of Sec. 3.2 should be relocated to a new Sec. service survives anticipated failures and degradations of the
3.4.1 (MPLS-TP PW Client), making the current 3.4.1 become 3.4.2, and MPLS-TP network.
be trimmed accordingly.
A new Sec. 3.2 on the overall architecture can then be written, which o Network management functions.
can perhaps be quite short and straightforward, leaving the fancy
diagrams for 3.4.1-2.
At the end of the current Sec. 3.2, we find that: The MPLS-TP architecture for LSPs and PWs includes the the following
two sets of functions:
The MPLS-TP definition applies to the following two domains: o MPLS-TP adaptation functions
o MPLS-TP Forwarding Domain o MPLS-TP forwarding functions
o MPLS-TP Transport Domain The adaptation functions interface the client service to MPLS-TP.
This includes the case where the client service is an MPLS-TP LSP.
For example, in the case of a PW, the adaptation function is the
payload encapsulation fillustrated in shown in Figure 4a of [RFC3985]
and Figure 7 of [I-D.ietf-pwe3-ms-pw-arch].
Neither term is defined. The first appears only as the name of the The forwarding functions comprise the mechanisms required for
next subsection, while the second appears only in the text at the forwarding the encapsulated client over an MPLS-TP server layer
beginning of Section 3.4. As well as proper definitions, there's network E.g. PW label and LSP label.
probably a real need for better terminology here; maybe "service" and
"transport", or "service" and "forwarding", or "adaptation" and
"forwarding".
. Suggestions for a new Section 3.2 (Architecture) 3.2.1. MPLS-TP Adaptation Functions
In a previous comment it was suggested to relocate the current The MPLS-TP adaptation functions interface the client service to
content of Section 3.2 to a new PW subsection of Section 3.4. MPLS-TP. For pseudowires, these adaptation functions are the payload
Following are the items it would be nice to see in a new Section 3.2 encapsulation shown in Figure 4a of [RFC3985] and Figure 7 of
covering the overall architecture: [I-D.ietf-pwe3-ms-pw-arch]. For network layer client services, the
adaptation function uses the MPLS encapsulation format as defined in
RFC 3032[RFC3032].
- summary of the device roles in an MPLS-TP network (CE, PE, P) - The purpose of this encapsulation is to abstract the client service
summary of the principal transport entities in an MPLS-TP network: data plane from the MPLS-TP data plane, thus contributing to the
Sections, LSPs (list/describe different types), PWs - summary of independent operation of the MPLS-TP network.
control plane options and protocols, provisioning methods - summary
of key OAM functions - summary of survivability options - explanation
of client-to-LSP mapping (see below) - summary of inter-domain
transport options (see below)
========= MPLS-TP is itself a client of an underlying server layer. MPLS-TP is
thus also bounded by a set of adaptation functions to this server
layer network, which may itself be MPLS-TP. These adaptation
functions provide encapsulation of the MPLS-TP frames and for the
transparent transport of those frames over the server layer network.
The MPLS-TP client inherits its QoS from the MPLS-TP network, which
in turn inherits its QoS from the server layer. The server layer
must therefore provide the necessary Quality of Service (QoS) to
ensure that the MPLS-TP client QoS commitments are satisfied.
The architecture for a transport profile of MPLS (MPLS-TP) that uses 3.2.2. MPLS-TP Forwarding Functions
PWs is based on the MPLS [RFC3031], pseudowire [RFC3985], and multi-
segment pseudowire [I-D.ietf-pwe3-ms-pw-arch] architectures, as
illustrated in Figure 3.
EDITORS'S NOTE - WE HAVE MODIFIED THE FIGS BELOW TO INCLUDE P ROUTERS The forwarding functions comprise the mechanisms required for
AND HAVE ADDED THE IP/MPLS LSP CASE. WE NEED TO REWRITE THE TEXT IN forwarding the encapsulated client over an MPLS-TP server layer
THIS SECTION TO ALIGN WITH THE CONTENTS OF THE FIGURES. network E.g. PW label and LSP label.
|<--------------- Client Service ----------------->| MPLS-TP LSPs use the MPLS label switching operations defined in
| | [RFC3031] for point-to-point LSPs and [RFC5332] for point to
| |<---- Pkt Xport Service --->| multipoint LSPs. These operations are highly optimized for
| | | | performance and are not modified by the MPLS-TP profile.
| | |<-- PSN Tunnel -->| | |
| V V V V |
V AC +----+ +---+ +----+ AC V
+-----+ | | PE1|======:=X=:=======| PE2| | +-----+
| |----------|...........:LSP:............|----------| |
| CE1 | | | | | : | | | | CE2 |
| |----------|...........: IP:............|----------| |
+-----+ ^ | | |======:=X=:=======| | | ^ +-----+
^ | +----+ +---+ +----+ | | ^
| | Provider Edge 1 ^ Provider Edge 2 | |
| | | | |
Customer | P Router | Customer
Edge 1 | | Edge 2
| |
| |
Native service Native service
Figure 2: MPLS-TP Architecture IP and LSP In addition, MPLS-TP PWs use the PW and MS-PW forwarding operations
defined in[RFC3985] and [I-D.ietf-pwe3-ms-pw-arch]. The PW label is
processed by a PW forwarder and is always at the bottom of the label
stack for a given MPLS-TP layer network.
Per-platform label space is used for PWs. Either per-platform or
per-interface label space may be used for LSPs.
During forwarding a label is pushed to associate a forwarding
equivalence class (FEC) with the LSP or PW. This specifies the
processing operation to be performed by the next hop at that level of
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
forwarder. The only event that interrupts a swap operation is TTL
expiry, in which case the packet may be inspected and either
discarded or subjected to further processing within the LSR. TTL
expiry causes an exception which forces a packet to be further
inspected and processed. While this occurs, the forwarding of
succeeding packets continues without interruption. Therefore, the
only way to cause a P (intermediate) LSR to inspect a packet (for
example for OAM purposes) is to set the TTL to expire at that LSR.
Point to point MPLS-TP LSPs can be either unidirectional or
bidirectional. Point-to-multipoint MPLS-TP LSPs are unidirectional.
Point-to-multipont PWs are currently being defined in the IETF and
may be incorporated in MPLS-TP if required.
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
i.e. they follow the same path. The pairing relationship between the
forward and the backward directions must be known at each LSR or LER
on a bidirectional LSP.
Per-packet equal cost multi-path (ECMP) load balancing is not
applicable to MPLS-TP LSPs.
Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by default.
Both E-LSP and L-LSP are supported in MPLS-TP, as defined in
[RFC3270].
The Traffic Class field (formerly the MPLS EXP field) follows the
definition and processing rules of [RFC5462] and [RFC3270]. Only the
pipe and short-pipe models are supported in MPLS-TP.
3.3. MPLS-TP LSP Clients
This document specifies the architecture for two types of client:
o A PW
o A network layer transport service
When the client is a PW, the MPLS-TP transport domain consists of the
PW encapsulation mechanisms, including the PW control word. When the
client is operating at the network layer the mechanism described in
Section 3.3.2 is used.
3.3.1. Pseudowires
The architecture for a transport profile of MPLS (MPLS-TP) that uses
PWs is based on the MPLS [RFC3031] and pseudowire [RFC3985]
architectures. If multi-segment pseudowires are used to provide a
packet transport service, motivated by, for example, the requirements
specified in [RFC5254] then the MS-PW architecture
[I-D.ietf-pwe3-ms-pw-arch] also applies.
Figure 2 shows the architecture for an MPLS-TP network using single-
segment PWs.
|<-------------- Emulated Service ---------------->| |<-------------- Emulated Service ---------------->|
| | | |
| |<------- Pseudowire ------->| | | |<------- Pseudowire ------->| |
| | encapsulated | | | | encapsulated | |
| | 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
skipping to change at page 13, line 28 skipping to change at page 13, line 31
+-----+ ^ | | |======:=X=:=======| | | ^ +-----+ +-----+ ^ | | |======:=X=:=======| | | ^ +-----+
^ | +----+ +---+ +----+ | | ^ ^ | +----+ +---+ +----+ | | ^
| | Provider Edge 1 ^ Provider Edge 2 | | | | Provider Edge 1 ^ Provider Edge 2 | |
| | | | | | | | | |
Customer | P Router | Customer Customer | P Router | Customer
Edge 1 | | Edge 2 Edge 1 | | Edge 2
| | | |
| | | |
Native service Native service Native service Native service
Figure 3: MPLS-TP Architecture (Single Segment PW) Figure 2: MPLS-TP Architecture (Single Segment PW)
Figure 3 shows the architecture for an MPLS-TP network when multi-
segment pseudowires are used. Note that as in the SS-PW case,
P-routers may also exist.
|<------------Pseudowire-------------->| |<------------Pseudowire-------------->|
| encapsulated | | encapsulated |
| Pkt Xport Service | | Pkt Xport Service |
| | | |
| PSN PSN | | PSN PSN |
AC | |<--tun1->| |<--tun2--->| | AC AC | |<--tun1->| |<--tun2--->| | AC
| V V V V V V | | V V V V V V |
| +----+ +-----+ +----+ | | +----+ +-----+ +----+ |
+----+ | |TPE1|===========|SPE1 |==========|TPE2| | +----+ +----+ | |TPE1|===========|SPE1 |==========|TPE2| | +----+
skipping to change at page 13, line 50 skipping to change at page 14, line 25
| CE1| | | | | | | | | |CE2 | | CE1| | | | | | | | | |CE2 |
| |------|..... PW.Seg't2....X....PW.Seg't4.....|-------| | | |------|..... PW.Seg't2....X....PW.Seg't4.....|-------| |
+----+ | | |===========| |==========| | | +----+ +----+ | | |===========| |==========| | | +----+
^ +----+ ^ +-----+ ^ +----+ ^ ^ +----+ ^ +-----+ ^ +----+ ^
| | | | | | | |
| TE LSP TE LSP | | TE LSP TE LSP |
| | | |
| | | |
|<---------------- Emulated Service ----------------->| |<---------------- Emulated Service ----------------->|
MPLS-TP Architecture (Multi-Segment PW) Figure 3: MPLS-TP Architecture (Multi-Segment PW)
The above figures illustrates the MPLS-TP architecture used to
provide a point-to-point packet transport service, or VPWS. In this
case, the MPLS-TP forwarding plane is a profile of the MPLS LSP and
SS-PW or MS-PW forwarding architecture as detailed in section
Section 3.3.
EDITORS NOTE reword next and add text to describe the IP/MPLS cases
This document describes the architecture for MPLS-TP when the LSP
client is a PW. The transport of IP and MPLS, other than carried
over a PW, is outside the scope of this document. This does not
preclude the use of LSPs conforming to the MPLS transport profile
from being used to carry IP or other MPLS LSPs by general purpose
MPLS networks. LSP hierarchy MAY be used within the MPLS-TP network,
so that more than one LSP label MAY appear in the label stack.
+---------------------------+ The corresponding domain of the MPLS-TP protocol stack including PWs
| Client service | is shown in Figure 4. In transport network nomenclature, the
/===========================\ <---- Normalised client pseudowire maps to the MPLS-TP channel, while the LSP maps to the
H Service LSP OAM H \ MPLS-TP path.
H---------------------------H } MPLS-TP channel
H Svc LSP Demux (S=1) H /
H---------------------------H \
H LSP OAM H \
H---------------------------H / MPLS-TP Path(s)
H LSP Demultiplexer(s) H /
\===========================/
| Server |
+---------------------------+
Figure 4: Domain of MPLS-TP Layer Network for IP and LSP Clients
+---------------------------+ +---------------------------+
| Client service | | Client service |
/===========================\ /===========================\
H PW Encapsulation H \ <---- PW Control word H PW Encapsulation H \ <---- PW Control word
H---------------------------H \ <---- Normalised client H---------------------------H \ <---- Normalised client
H PW OAM H MPLS-TP channel H PW OAM H MPLS-TP channel
H---------------------------H / H---------------------------H /
H PW Demux (S=1) H / H PW Demux (S=1) H /
H---------------------------H \ H---------------------------H \
H LSP OAM H \ H LSP OAM H \
H---------------------------H / MPLS-TP Path(s) H---------------------------H / MPLS-TP Path(s)
H LSP Demultiplexer(s) H / H LSP Demultiplexer(s) H /
\===========================/ \===========================/
| Server | | Server |
+---------------------------+ +---------------------------+
Figure 5: Domain of MPLS-TP Layer Network using Pseudowires Figure 4: Domain of MPLS-TP Layer Network using Pseudowires
Figure (Figure 5) illustrates the protocol stack to be used when
pseudowires are carried over MPLS-TP LSPs.
When providing a VPWS, VPLS, VPMS or IPLS, pseudowires MUST be used When providing a Virtual Private Wire Service (VPWS), Virtual Private
to carry a client service. For compatibility with transport Local Area Network Service (VPLS), Virtual Private Multicast Service
nomenclature, the PW may be referred to as the MPLS-TP Channel and (VPMS) or Internet Protocol Local Area Network Service (IPLS),
the LSP may be referred to as the MPLS-TP Path. pseudowires MUST be used to carry a client service.
Note that in MPLS-TP environments where IP is used for control or OAM Note that in MPLS-TP environments where IP is used for control or OAM
purposes, IP MAY be carried over the LSP demultiplexers as per purposes, IP MAY be carried over the LSP demultiplexers as per
RFC3031 [RFC3031], or directly over the server. RFC3031 [RFC3031], or directly over the server.
PW OAM, PSN OAM and PW client data are mutually exclusive and never 3.3.2. Network Layer Clients
exist in the same packet.
The MPLS-TP definition applies to the following two domains:
o MPLS-TP Forwarding Domain
o MPLS-TP Transport Domain
3.3. MPLS-TP Forwarding Domain
A set of client-to-MPLS-TP adaptation functions interface the client
to MPLS-TP. For pseudowires, this adaptation function is the PW
forwarder shown in Figure 4a of [RFC3985]. The PW label is used for
forwarding in this case and is always at the bottom of the label
stack. The operation of the MPLS-TP network is independent of the
payload carried by the MPLS-TP PW packet.
MPLS-TP is itself a client of an underlying server layer. MPLS-TP is
thus bounded by a set of adaptation functions to this server layer
network. These adaptation functions provide encapsulation of the
MPLS-TP frames and for the transparent transport of those frames over
the server layer network. The MPLS-TP client inherits its QoS from
the MPLS-TP network, which in turn inherits its QoS from the server
layer. The server layer must therefore provide the necessary Quality
of Service (QoS) to ensure that the MPLS-TP client QoS commitments
are satisfied.
MPLS-TP LSPs use the MPLS label switching operations defined in
[RFC3031] for point-to-point LSPs and [RFC5332] for point to
multipoint LSPs. These operations are highly optimized for
performance and are not modified by the MPLS-TP profile.
During forwarding a label is pushed to associate a forwarding
equivalence class (FEC) with the LSP or PW. This specifies the
processing operation to be performed by the next hop at that level of
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
forwarder. The only event that interrupts a swap operation is TTL
expiry, in which case the packet may be inspected and either
discarded or subjected to further processing within the LSR. TTL
expiry causes an exception which forces a packet to be further
inspected and processed. While this occurs, the forwarding of
succeeding packets continues without interruption. Therefore, the
only way to cause a P (intermediate) LSR to inspect a packet (for
example for OAM purposes) is to set the TTL to expire at that LSR.
MPLS-TP PWs support the PW and MS-PW forwarding operations defined
in[RFC3985] and [I-D.ietf-pwe3-ms-pw-arch].
The Traffic Class field (formerly the MPLS EXP field) follows the
definition and processing rules of [RFC5462] and [RFC3270]. Only the
pipe and short-pipe models are supported in MPLS-TP.
The MPLS encapsulation format is as defined in RFC 3032[RFC3032].
Per-platform label space is used for PWs. Either per-platform or
per-interface label space may be used for LSPs.
Point to point MPLS-TP LSPs can be either unidirectional or
bidirectional. Point-to-multipoint MPLS-TP LSPs are unidirectional.
Point-to-multipont PWs are currently being defined in the IETF and
may be incorporated in MPLS-TP if required.
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
i.e. they follow the same path. The pairing relationship between the
forward and the backward directions must be known at each LSR or LER
on a bidirectional LSP.
Per-packet equal cost multi-path (ECMP) load balancing is not
applicable to MPLS-TP LSPs.
Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by default.
Both E-LSP and L-LSP are supported in MPLS-TP, as defined in RFC 3270
[RFC3270]
3.4. MPLS-TP LSP Clients
This document specifies the architecture for two types of client:
o A PW
o A network layer transport service MPLS-TP LSPs can be used to deliver a transport service for network
layer clients. Such a network layer transport service (NLTS) can be
used to transport any network layer protocol between service
interfaces. Examples of network layer protocols include IP, MPLS and
MPLS-TP.
When the client is a PW, the MPLS-TP transport domain consists of the |<--------------- Client Service ----------------->|
PW encapsulation mechanisms, including the PW control word. When the | |
client is operating at the network layer the mechanism described in | |<---- Pkt Xport Service --->|
Section 3.4.1 is used. | | | |
| | |<-- PSN Tunnel -->| | |
| V V V V |
V AC +----+ +---+ +----+ AC V
+-----+ | | PE1|======:=X=:=======| PE2| | +-----+
| |----------|...........:LSP:............|----------| |
| CE1 | | | | | : | | | | CE2 |
| |----------|...........: IP:............|----------| |
+-----+ ^ | | |======:=X=:=======| | | ^ +-----+
^ | +----+ +---+ +----+ | | ^
| | Provider Edge 1 ^ Provider Edge 2 | |
| | | | |
Customer | P Router | Customer
Edge 1 | | Edge 2
| |
| |
Native service Native service
3.4.1. Network Layer Transport Service Figure 5: MPLS-TP Architecture for Network Layer Clients
+---------------------------+
| Client service |
/===========================\ <---- Normalised client
H Service LSP OAM H \
H---------------------------H } MPLS-TP channel
H Svc LSP Demux (S=1) H /
H---------------------------H \
H LSP OAM H \
H---------------------------H / MPLS-TP Path(s)
H LSP Demultiplexer(s) H /
\===========================/
| Server |
+---------------------------+
MPLS-TP LSPs can be used to deliver a network level transport Figure 6: Domain of MPLS-TP Layer Network for IP and LSP Clients
service. Such a network layer transport service (NLTS) can be used
to transport any network layer protocol between service interfaces.
Examples of network layer protocols include IP, MPLS and MPLS-TP.
With network layer transport, the MPLS-TP domain provides a With network layer transport, the MPLS-TP domain provides a
bidirectional point-to-point connection between two customer edge bidirectional point-to-point connection between two customer edge
(CE) MPLS-TP nodes. Point-to- multipoint service is for further (CE) nodes. Note that a CE may be an an IP, MPLS or MPLS-TP node.
study. As shown in Figure 6, there is an attachment circuit between Point-to- multipoint service is for further study. As shown in
the CE node on the left and its corresponding provider edge (PE) node Figure 7, there is an attachment circuit between the CE node on the
that provides the service interface, a bidirectional LSP across the left and its corresponding provider edge (PE) node that provides the
MPLS-TP service network to the corresponding PE node on the right, service interface, a bidirectional LSP across the MPLS-TP service
and an attachment circuit between that PE node and the corresponding network to the corresponding PE node on the right, and an attachment
CE node for this service. circuit between that PE node and the corresponding CE node for this
service.
: +--------------------+ : : +--------------------+ :
: | +------------+ | : : | +------------+ | :
: | | Management | | : : | | Management | | :
+------+ : | | system(s) | | : +------+ +------+ : | | system(s) | | : +------+
| C | : | +------------+ | : | CE | +------+ | C | : | +------------+ | : | CE | +------+
|device| : | | : |device|--| C | |device| : | | : |device|--| C |
+------+ : | +------+ : | of | |device| +------+ : | +------+ : | of | |device|
| : | | x=:=|SVC A| +------+ | : | | x=:=|SVC A| +------+
| : | | | : +------+ | : | | | : +------+
skipping to change at page 18, line 43 skipping to change at page 17, line 43
Customer | | Customer Customer | | Customer
interface | MPLS-TP | interface interface | MPLS-TP | interface
+--------------------+ +--------------------+
|<---- Provider ---->| |<---- Provider ---->|
| network | | network |
Key: ==== attachment circuit Key: ==== attachment circuit
x service interface x service interface
---- link ---- link
Figure 6: Network Layer Transport Service Components Figure 7: Network Layer Transport Service Components
At the service interface the PE transforms the ingress packet to the At the service interface the PE transforms the ingress packet to the
format that will be carried over the transport network, and similarly format that will be carried over the transport network, and similarly
the corresponding service interface at the egress PE transforms the the corresponding service interface at the egress PE transforms the
packet to the format needed by the attached CE. The attachment packet to the format needed by the attached CE. The attachment
circuits may be heterogeneous (e.g., any combination of SDH, PPP, circuits may be heterogeneous (e.g., any combination of SDH, PPP,
Frame Relay etc) and network layer protocol payloads arrive at the Frame Relay etc) and network layer protocol payloads arrive at the
service interface encapsulated in the Layer1/Layer2 encoding defined service interface encapsulated in the Layer1/Layer2 encoding defined
for that access link type. It should be noted that the set of for that access link type. It should be noted that the set of
network layer protocols includes MPLS and hence MPLS encoded packets network layer protocols includes MPLS and hence MPLS encoded packets
with an MPLS label stack (the client MPLS stack), may appear at the with an MPLS label stack (the client MPLS stack), may appear at the
service interface. service interface.
EDITOR'S NOTE John, Lou and Rahul please note that this next para has
been added.
Note the case where either or both the attachment circuits are a LAN
needs additional specification which is outside the scope of this
document. This mode of operation requires that the PE participated
in the client network for example to execute neighbor discover
protocols such as ARP and IPv6 neighbor discovery. Operation can be
achieved through the mechanisms described in
[I-D.ietf-l2vpn-arp-mediation], which includes the case of static
configuration of the CE IP addresses on the PEs.
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 LSP using a separate MPLS label stack (the carried over the MPLS-TP LSP using a separate MPLS label stack (the
server stack). The server stack is entirely under the control of the server stack). The server stack is entirely under the control of the
nodes within the MPLS-TP transport network and it is not visible nodes within the MPLS-TP transport network and it is not visible
outside that network. In accordance with [RFC3032], the bottom outside that network. In accordance with [RFC3032], the bottom
label, with the 'bottom of stack' bit set to '1', defines the network label, with the 'bottom of stack' bit set to '1', defines the network
layer protocol being transported. Figure 7 shows how an a client layer protocol being transported. Figure 8 shows how an 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 as a network layer transport service over an MPLS-TP is carried over as a network layer transport service over an MPLS-TP
transport network. transport network.
+------------------------------------+ +------------------------------------+
| MPLS-TP LSP label(s) (S=0) | n*4 octets | MPLS-TP LSP label(s) (S=0) | n*4 octets
. . (four octets per label) . . (four octets per label)
+------------------------------------+ +------------------------------------+
| Service label (s=1) | 4 octets | Service label (s=1) | 4 octets
+------------------------------------+ +------------------------------------+
| Client Network | | Client Network |
| Layer Protocol | | Layer Protocol |
| Stack. | | Stack. |
+------------------------------------+ +------------------------------------+
Note that the Client Network Layer Protocol Note that the Client Network Layer Protocol
Stack may include an MPLS label stack Stack may include an MPLS label stack
with the S bit set (S=1). with the S bit set (S=1).
Figure 7: Network Layer Transport Service Protocol Stack Figure 8: Network Layer Transport Service Protocol Stack
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 "Service transported is REQUIRED. Such labels are referred to as "Service
Labels", one of which is shown in Figure 7. The mapping between Labels", one of which is shown in Figure 8. The mapping between
protocol payload type and Service Label is either configured or protocol payload type and Service Label is either configured or
signaled. signaled.
Service labels are typically carried over an MPLS-TP edge-to-edge Service labels are typically carried over an MPLS-TP edge-to-edge
LSP, which is also shown in Figure 7. The use of an edge-to-edge LSP LSP, which is also shown in Figure 8. The use of an edge-to-edge LSP
is RECOMMENDED when more than one protocol payload type is to be is RECOMMENDED when more than one protocol payload type is to be
transported. For example, if only MPLS is carried then a single transported. For example, if only MPLS is carried then a single
Service Label would be used to provided both payload type indication Service Label would be used to provided both payload type indication
and the MPLS-TP edge-to-edge LSP. Alternatively, if both IP and MPLS and the MPLS-TP edge-to-edge LSP. Alternatively, if both IP and MPLS
is to be carried then two Service Labels would be mapped on to a is to be carried then two Service Labels would be mapped on to a
common MPLS-TP edge-to-edge LSP. common MPLS-TP edge-to-edge LSP.
As noted above, any layer 2 and layer 1 protocols used to carry the As noted above, any layer 2 and layer 1 protocols used to carry the
network layer protocol over the attachment circuit is terminated at network layer protocol over the attachment circuit is terminated at
the service interface and is not transported across the MPLS-TP the service interface and is not transported across the MPLS-TP
skipping to change at page 20, line 38 skipping to change at page 19, line 27
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. (Examples for the Ethernet case include a covered in this document. (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.)
A PE MAY be configured to participate in the client network's link
layer in order to simplify CE configuration, for example to execute
neighbor discover protocols such as Address Resolution Protocol
(ARP), [RFC0826], inverse ARP[RFC2390], IPv6 neighbor discovery
[RFC2461] or IPv6 inverse neighbor discovery[RFC3122]. Mechanisms to
achieve such participation are outside the scope of this document.
See [I-D.ietf-l2vpn-arp-mediation] for an example mechanism.
Note that when the two CEs operating over the network layer transport Note that when the two CEs operating over the network layer transport
service are running a routing protocol such as ISIS or OSPF some care service are running a routing protocol such as ISIS or OSPF some care
should be taken to configure the routing protocols to use point- to- should be taken to configure the routing protocols to use point- to-
point adjacencies. The specifics of such configuration is outside point adjacencies. The specifics of such configuration is outside
the scope of this document. the scope of this document.
[Editors Note we need to confer with ISIS and OSPF WG to verify that [Editors Note we need to confer with ISIS and OSPF WG to verify that
the cautionary note above is necessary and sufficient.] the cautionary note above is necessary and sufficient.]
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. When they are signaled the CE to PE control channel may or signaled. When they are signaled the CE to PE control channel may
be either out-of-band or in-band. An out-of-band control channel be either out-of-band or in-band. An out-of-band control channel
uses standard GMPLS out-of-band signaling techniques [REF-TBD]. uses standard GMPLS out-of-band signaling techniques. There are a
There are a number of methods that can be used to carry this number of methods that can be used to carry this signalling:
signalling:
o It can be carried via an out-of-band control channel. (As is o It can be carried via an out-of-band control channel. (As is
commonly done in today's GMPLS controlled transport networks.) commonly done in today's GMPLS controlled transport networks.)
o It could be carried over the attachment circuit with MPLS using a o It could be carried over the attachment circuit with MPLS using a
reserved label. reserved label.
o It could be carried over the attachment circuit with MPLS using a o It could be carried over the attachment circuit with MPLS using a
normal label that is agreed between CE and PE. normal label that is agreed between CE and PE.
skipping to change at page 21, line 27 skipping to change at page 20, line 23
o It could be carried over the attachment circuit in IP. o It could be carried over the attachment circuit in IP.
In the MPLS and ACH cases above, this label value is used to carry In the MPLS and ACH cases above, this label value is used to carry
LSP signaling without any further encapsulation. This signaling LSP signaling without any further encapsulation. This signaling
channel is always point-to-point and MUST use local CE and PE channel is always point-to-point and MUST use local CE and PE
addressing. addressing.
The method(s) to be used will be described in a future version of the The method(s) to be used will be described in a future version of the
document. document.
3.5. Identifiers 3.4. Identifiers
Identifiers to be used in within MPLS-TP where compatibility with Identifiers to be used in within MPLS-TP where compatibility with
existing MPLS control plane conventions are necessary are described existing MPLS control plane conventions are necessary are described
in [draft-swallow-mpls-tp-identifiers-00]. The MPLS-TP requirements in [draft-swallow-mpls-tp-identifiers-00]. The MPLS-TP requirements
[I-D.ietf-mpls-tp-requirements] require that the elements and objects [RFC5654] require that the elements and objects in an MPLS-TP
in an MPLS-TP environment are able to be configured and managed environment are able to be configured and managed without a control
without a control plane. In such an environment many conventions for plane. In such an environment many conventions for defining
defining identifiers are possible. However it is also anticipated identifiers are possible. However it is also anticipated that
that operational environments where MPLS-TP objects, LSPs and PWs operational environments where MPLS-TP objects, LSPs and PWs will be
will be signaled via existing protocols such as the Label signaled via existing protocols such as the Label Distribution
Distribution Protocol [RFC4447] and the Resource Reservation Protocol Protocol [RFC4447] and the Resource Reservation Protocol as it is
as it is applied to Generalized Multi-protocol Label Switching ( applied to Generalized Multi-protocol Label Switching ( [RFC3471] and
[RFC3471] and [RFC3473]) (GMPLS). [RFC3473]) (GMPLS). [draft-swallow-mpls-tp-identifiers-00] defines a
[draft-swallow-mpls-tp-identifiers-00] defines a set of identifiers set of identifiers for MPLS-TP which are both compatible with those
for MPLS-TP which are both compatible with those protocols and protocols and applicable to MPLS-TP management and OAM functions.
applicable to MPLS-TP management and OAM functions.
MPLS-TP distinguishes between addressing used to identify nodes in MPLS-TP distinguishes between addressing used to identify nodes in
the network, and identifiers used for demultiplexing and forwarding. the network, and identifiers used for demultiplexing and forwarding.
Whilst IP addressing is used by default, MPLS-TP must be able to Whilst IP addressing is used by default, MPLS-TP must be able to
operate in environments where IP is not used in the forwarding plane. operate in environments where IP is not used in the forwarding plane.
Therefore, the default mechanism for OAM demultiplexing in MPLS-TP Therefore, the default mechanism for OAM demultiplexing in MPLS-TP
LSPs and PWs is the generic associated channel. Forwarding based on LSPs and PWs is the generic associated channel. Forwarding based on
IP addresses for user or OAM packets is not REQUIRED for MPLS-TP. IP addresses for user or OAM packets is not REQUIRED for MPLS-TP.
[RFC4379]and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have defined alert [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 OAM mechanisms that enable an MPLS LSR to identify and process MPLS OAM
packets when the OAM packets are encapsulated in an IP header. These packets when the OAM packets are encapsulated in an IP header. These
alert mechanisms are based on TTL expiration and/or use an IP alert mechanisms are based on TTL expiration and/or use an IP
destination address in the range 127/8. These mechanisms are the destination address in the range 127/8. These mechanisms are the
default mechanisms for MPLS networks in general for identifying MPLS default mechanisms for MPLS networks in general for identifying 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.
MPLS-TP is unable to rely on the availability of IP and thus uses the MPLS-TP is unable to rely on the availability of IP and thus uses the
GACH/GAL to demultiplex OAM packets. GACH/GAL to demultiplex OAM packets.
3.6. Operations, Administration and Maintenance (OAM) 3.5. Operations, Administration and Maintenance (OAM)
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 LSP. These mechanisms are described in [RFC5586]. same LSP. These mechanisms are 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 localization) and performance monitoring (e.g. packet detection and localization) 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].
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 (or more) Maintenance Entity can be viewed as the association of two (or more)
Maintenance End Points (MEPs) (see example in Figure 8 ). The MEPs Maintenance End Points (MEPs) (see example in Figure 9 ). The MEPs
that form an ME should be configured and managed to limit the OAM that form an ME should be configured and managed to limit the OAM
responsibilities of an OAM flow within a network or sub- network, or responsibilities of an OAM flow within a network or sub- network, or
a transport path or segment, in the specific layer network that is a transport path or segment, in the specific layer network that is
being monitored and managed. being monitored and managed.
Each OAM flow is associated with a single ME. Each MEP within an ME Each OAM flow is associated with a single ME. Each MEP within an ME
resides at the boundaries of that ME. An ME may also include a set resides at the boundaries of that ME. An ME may also include a set
of zero or more Maintenance Intermediate Points (MIPs), which reside of zero or more Maintenance Intermediate Points (MIPs), which reside
within the Maintenance Entity. Maintenance end points (MEPs) are within the Maintenance Entity. Maintenance end points (MEPs) are
capable of sourcing and sinking OAM flows, while maintenance capable of sourcing and sinking OAM flows, while maintenance
skipping to change at page 23, line 28 skipping to change at page 22, line 28
(Carrier 1) LSP OAM (Carrier 2) (Carrier 1) LSP OAM (Carrier 2)
(inter-carrier) (inter-carrier)
..... ..... ..... .......... .......... ..... ..... ..... ..... ..... .......... .......... ..... .....
|MEP|---|MIP|---|MIP|--|MEP||MEP|---|MEP||MEP|--|MIP|----|MEP| |MEP|---|MIP|---|MIP|--|MEP||MEP|---|MEP||MEP|--|MIP|----|MEP|
''''' ''''' ''''' '''''''''' '''''''''' ''''' ''''' ''''' ''''' ''''' '''''''''' '''''''''' ''''' '''''
<------------ ME ----------><--- ME ----><------- ME --------> <------------ ME ----------><--- ME ----><------- ME -------->
Note: MEPs for End-to-end LSP OAM exist outside of the scope Note: MEPs for End-to-end LSP OAM exist outside of the scope
of this figure. of this figure.
Figure 8: Example of MPLS-TP OAM Figure 9: Example of MPLS-TP OAM
Figure 9 illustrates how the concept of Maintenance Entities can be Figure 10 illustrates how the concept of Maintenance Entities can be
mapped to sections, LSPs and PWs in an MPLS-TP network that uses MS- mapped to sections, LSPs and PWs in an MPLS-TP network that uses MS-
PWs. PWs.
Native |<-------------------- PW15 --------------------->| Native Native |<-------------------- PW15 --------------------->| Native
Layer | | Layer Layer | | Layer
Service | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | Service Service | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | Service
(AC1) V V LSP V V LSP V V LSP V V (AC2) (AC1) V V LSP V V LSP V V LSP V V (AC2)
+----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+ +----+ +-+ +----+
+---+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +---+ +---+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +---+
| | | |=========| |=========| |=========| | | | | | | |=========| |=========| |=========| | | |
skipping to change at page 24, line 36 skipping to change at page 23, line 36
TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge 3 TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge 3
TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge Z TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge Z
.---. ME . MEP ==== LSP .... PW .---. ME . MEP ==== LSP .... PW
SME: Section Maintenance Entity SME: Section Maintenance Entity
LME: LSP Maintenance Entity LME: LSP Maintenance Entity
PME: PW Maintenance Entity PME: PW Maintenance Entity
Figure 9: MPLS-TP OAM archtecture Figure 10: MPLS-TP OAM archtecture
The following MPLS-TP MEs are specified in The following MPLS-TP MEs are specified in
[I-D.ietf-mpls-tp-oam-framework]: [I-D.ietf-mpls-tp-oam-framework]:
o A Section Maintenance Entity (SME), allowing monitoring and o A Section Maintenance Entity (SME), allowing monitoring and
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 end-to-end LSP (between LERs). of an end-to-end LSP (between LERs).
skipping to change at page 26, line 11 skipping to change at page 25, line 11
the case of MPLS-TP deployment with IP functionality, all existing the case of MPLS-TP deployment with IP functionality, all existing
IP-MPLS OAM functions, e.g. LSP-Ping, BFD and VCCV, may be used. IP-MPLS OAM functions, e.g. LSP-Ping, BFD and VCCV, may be used.
This does not preclude the use of other OAM tools in an IP This does not preclude the use of other OAM tools in an IP
addressable network. addressable network.
One use of OAM mechanisms is to detect link failures, node failures One use of OAM mechanisms is to detect link failures, node failures
and performance outside the required specification which then may be and performance outside the required specification which then may be
used to trigger recovery actions, according to the requirements of used to trigger recovery actions, according to the requirements of
the service. the service.
3.7. 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 MPSL-TP it is fate share with the data packets. In addition in MPSL-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 the packet may contain a Signaling of payload. For example the packet may contain a Signaling
Communication Channel (SCC), or a channel used for Automatic Communication Channel (SCC), or a channel used for Automatic
Protection Switching (APS) data. Such packets are carried on a Protection Switching (APS) data. Such packets are carried on a
control channel associated to the LSP, Section or PW. This is control channel associated to the LSP, Section or PW. This is
achieved by carrying such packets on a generic control channel achieved by carrying such packets on a generic control channel
associated to the LSP, PW or section. associated to the LSP, PW or section.
skipping to change at page 27, line 36 skipping to change at page 26, line 36
a PW type. a PW type.
Since the G-ACh traffic is indistinguishable from the user data Since the G-ACh traffic is indistinguishable from the user data
traffic at the server layer, bandwidth and QoS commitments apply to traffic at the server layer, bandwidth and QoS commitments apply to
the gross traffic on the LSP, PW or section. Protocols using the the gross traffic on the LSP, PW or section. Protocols using the
G-ACh must therefore take into consideration the impact they have on G-ACh must therefore take into consideration the impact they have on
the user data that they are sharing resources with. In addition, the user data that they are sharing resources with. In addition,
protocols using the G-ACh MUST conform to the security and congestion protocols using the G-ACh MUST conform to the security and congestion
considerations described in [RFC5586]. . considerations described in [RFC5586]. .
Figure 10 shows the reference model depicting how the control channel Figure 11 shows the reference model depicting how the control channel
is associated with the pseudowire protocol stack. This is based on is associated with the pseudowire protocol stack. This is based on
the reference model for VCCV shown in Figure 2 of [RFC5085]. the reference model for VCCV shown in Figure 2 of [RFC5085].
+-------------+ +-------------+ +-------------+ +-------------+
| Payload | < Service / FCAPS > | Payload | | Payload | < Service / FCAPS > | Payload |
+-------------+ +-------------+ +-------------+ +-------------+
| Demux / | < CW / ACH for PWs > | Demux / | | Demux / | < CW / ACH for PWs > | Demux / |
|Discriminator| |Discriminator| |Discriminator| |Discriminator|
+-------------+ +-------------+ +-------------+ +-------------+
| PW | < PW > | PW | | PW | < PW > | PW |
skipping to change at page 28, line 27 skipping to change at page 27, line 27
| | | |
| ____ ___ ____ | | ____ ___ ____ |
| _/ \___/ \ _/ \__ | | _/ \___/ \ _/ \__ |
| / \__/ \_ | | / \__/ \_ |
| / \ | | / \ |
+--------| MPLS/MPLS-TP Network |---+ +--------| MPLS/MPLS-TP Network |---+
\ / \ /
\ ___ ___ __ _/ \ ___ ___ __ _/
\_/ \____/ \___/ \____/ \_/ \____/ \___/ \____/
Figure 10: PWE3 Protocol Stack Reference Model including the G-ACh Figure 11: PWE3 Protocol Stack Reference Model including the G-ACh
PW associated channel messages are encapsulated using the PWE3 PW associated channel messages are encapsulated using the PWE3
encapsulation, so that they are handled and processed in the same encapsulation, so that they are handled and processed in the same
manner (or in some cases, an analogous manner) as the PW PDUs for manner (or in some cases, an analogous manner) as the PW PDUs for
which they provide a control channel. which they provide a control channel.
Figure 11 shows the reference model depicting how the control channel Figure 12 shows the reference model depicting how the control channel
is associated with the LSP protocol stack. is associated with the LSP protocol stack.
+-------------+ +-------------+ +-------------+ +-------------+
| Payload | < Service > | Payload | | Payload | < Service > | Payload |
+-------------+ +-------------+ +-------------+ +-------------+
|Discriminator| < ACH on LSP > |Discriminator| |Discriminator| < ACH on LSP > |Discriminator|
+-------------+ +-------------+ +-------------+ +-------------+
|Demultiplexer| < GAL on LSP > |Demultiplexer| |Demultiplexer| < GAL on LSP > |Demultiplexer|
+-------------+ +-------------+ +-------------+ +-------------+
| PSN | < LSP > | PSN | | PSN | < LSP > | PSN |
skipping to change at page 29, line 26 skipping to change at page 28, line 26
| | | |
| ____ ___ ____ | | ____ ___ ____ |
| _/ \___/ \ _/ \__ | | _/ \___/ \ _/ \__ |
| / \__/ \_ | | / \__/ \_ |
| / \ | | / \ |
+--------| MPLS/MPLS-TP Network |---+ +--------| MPLS/MPLS-TP Network |---+
\ / \ /
\ ___ ___ __ _/ \ ___ ___ __ _/
\_/ \____/ \___/ \____/ \_/ \____/ \___/ \____/
Figure 11: MPLS Protocol Stack Reference Model including the LSP Figure 12: MPLS Protocol Stack Reference Model including the LSP
Associated Control Channel Associated Control Channel
3.8. Control Plane 3.7. Control Plane
MPLS-TP should be capable of being operated with centralized Network MPLS-TP should be capable of being operated with centralized Network
Management Systems (NMS). The NMS may be supported by a distributed Management Systems (NMS). The NMS may be supported by a distributed
control plane, but MPLS-TP can operated in the absence of such a control plane, but MPLS-TP can operated in the absence of such a
control plane. A distributed control plane may be used to enable control plane. A distributed control plane may be used to enable
dynamic service provisioning in multi-vendor and multi-domain dynamic service provisioning in multi-vendor and multi-domain
environments using standardized protocols that guarantee environments using standardized protocols that guarantee
interoperability. Where the requirements specified in interoperability. Where the requirements specified in [RFC5654] can
[I-D.ietf-mpls-tp-requirements] can be met, the MPLS transport be met, the MPLS transport profile uses existing control plane
profile uses existing control plane protocols for LSPs and PWs. protocols for LSPs and PWs.
Figure 12 illustrates the relationship between the MPLS-TP control Figure 13 illustrates the relationship between the MPLS-TP control
plane, the forwarding plane, the management plane, and OAM for point- plane, the forwarding plane, the management plane, and OAM for point-
to-point MPLS-TP LSPs or PWs. to-point MPLS-TP LSPs or PWs.
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| | | |
| Network Management System and/or | | Network Management System and/or |
| | | |
| Control Plane for Point to Point Connections | | Control Plane for Point to Point Connections |
| | | |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
skipping to change at page 30, line 32 skipping to change at page 29, line 32
''''''''''''''''''''''' ''''''''''''''' ''''''''''''''''''''''' ''''''''''''''''''''''' ''''''''''''''' '''''''''''''''''''''''
Note: Note:
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, and LSP or a G-ACh. layer, and LSP or a G-ACh.
Figure 12: MPLS-TP Control Plane Architecture Context Figure 13: MPLS-TP Control Plane Architecture Context
The MPLS-TP control plane is based on a combination of the LDP-based The MPLS-TP control plane is based on a combination of the LDP-based
control plane for pseudowires [RFC4447] and the RSVP-TE based control control plane for pseudowires [RFC4447] and the RSVP-TE based control
plane for MPLS-TP LSPs [RFC3471]. Some of the RSVP-TE functions that plane for MPLS-TP LSPs [RFC3471]. Some of the RSVP-TE functions that
are required for LSP signaling for MPLS-TP are based on GMPLS. are required for LSP signaling for MPLS-TP are based on GMPLS.
The distributed MPLS-TP control plane provides the following The distributed MPLS-TP control plane provides the following
functions: functions:
o Signaling o Signaling
skipping to change at page 31, line 9 skipping to change at page 30, line 9
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
the information exchanged across these interface types. the information exchanged across these interface types.
The MPLS-TP control plane is capable of activating MPLS-TP OAM The MPLS-TP control plane is capable of activating MPLS-TP OAM
functions as described in the OAM section of this document functions as described in the OAM section of this document
Section 3.6 e.g. for fault detection and localization in the event of Section 3.5 e.g. for fault detection and localization in the event of
a failure in order to efficiently restore failed transport paths. a failure in order to efficiently restore failed transport paths.
The MPLS-TP control plane supports all MPLS-TP data plane The MPLS-TP control plane supports all MPLS-TP data plane
connectivity patterns that are needed for establishing transport connectivity patterns that are needed for establishing transport
paths including protected paths as described in the survivability paths including protected paths as described in the survivability
section Section 3.10 of this document. Examples of the MPLS-TP data section Section 3.9 of this document. Examples of the MPLS-TP data
plane connectivity patterns are LSPs utilizing the fast reroute plane connectivity patterns are LSPs utilizing the fast reroute
backup methods as defined in [RFC4090] and ingress-to-egress 1+1 or backup methods as defined in [RFC4090] and ingress-to-egress 1+1 or
1:1 protected LSPs. 1:1 protected LSPs.
The MPLS-TP control plane provides functions to ensure its own The MPLS-TP control plane provides functions to ensure its own
survivability and to enable it to recover gracefully from failures survivability and to enable it to recover gracefully from failures
and degradations. These include graceful restart and hot redundant and degradations. These include graceful restart and hot redundant
configurations. Depending on how the control plane is transported, configurations. Depending on how the control plane is transported,
varying degrees of decoupling between the control plane and data varying degrees of decoupling between the control plane and data
plane may be achieved. plane may be achieved.
3.8.1. PW Control Plane 3.7.1. PW Control Plane
An MPLS-TP network provides many of its transport services using An MPLS-TP network provides many of its transport services using
single-segment or multi-segment pseudowires, in compliance with the single-segment or multi-segment pseudowires, in compliance with the
PWE3 architecture ([RFC3985] and [I-D.ietf-pwe3-ms-pw-arch] ). The PWE3 architecture ([RFC3985] and [I-D.ietf-pwe3-ms-pw-arch] ). The
setup and maintenance of single-segment or multi- segment pseudowires setup and maintenance of single-segment or multi- segment pseudowires
uses the Label Distribution Protocol (LDP) as per [RFC4447] and uses the Label Distribution Protocol (LDP) as per [RFC4447] and
extensions for MS-PWs [I-D.ietf-pwe3-segmented-pw] and extensions for MS-PWs [I-D.ietf-pwe3-segmented-pw] and
[I-D.ietf-pwe3-dynamic-ms-pw]. [I-D.ietf-pwe3-dynamic-ms-pw].
3.8.2. LSP Control Plane 3.7.2. LSP Control Plane
MPLS-TP provider edge nodes aggregate multiple pseudowires and carry MPLS-TP provider edge nodes aggregate multiple pseudowires and carry
them across the MPLS-TP network through MPLS-TP tunnels (MPLS-TP them across the MPLS-TP network through MPLS-TP tunnels (MPLS-TP
LSPs). Applicable functions from the Generalized MPLS (GMPLS) LSPs). Applicable functions from the Generalized MPLS (GMPLS)
protocol suite supporting packet-switched capable (PSC) technologies protocol suite supporting packet-switched capable (PSC) technologies
are used as the control plane for MPLS-TP transport paths (LSPs). are used as the control plane for MPLS-TP transport paths (LSPs).
The LSP control plane includes: The LSP control plane includes:
o RSVP-TE for signalling o RSVP-TE for signalling
skipping to change at page 32, line 18 skipping to change at page 31, line 18
RSVP explicit route object (ERO) is utilized for the setup of the RSVP explicit route object (ERO) is utilized for the setup of the
transport path exactly following the given route. GMPLS based transport path exactly following the given route. GMPLS based
MPLS-TP LSPs must be able to inter-operate with RSVP-TE based MPLS-TE MPLS-TP LSPs must be able to inter-operate with RSVP-TE based MPLS-TE
LSPs, as per [RFC5146] LSPs, as per [RFC5146]
OSPF-TE routing in support of GMPLS as defined in [RFC4203] is used OSPF-TE routing in support of GMPLS as defined in [RFC4203] is used
for carrying link state information in a MPLS-TP network. ISIS-TE for carrying link state information in a MPLS-TP network. ISIS-TE
routing in support of GMPLS as defined in [RFC5307] is used for routing in support of GMPLS as defined in [RFC5307] is used for
carrying link state information in a MPLS-TP network. carrying link state information in a MPLS-TP network.
3.9. Static Operation of LSPs and PWs 3.8. 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
dynamic control plane. This may be either by direct configuration of dynamic control plane. This may be either by direct configuration of
the PEs/LSRs, or via a network management system. The collateral the PEs/LSRs, or via a network management system. The collateral
damage that loops can cause during the time taken to detect the damage that loops can cause during the time taken to detect the
failure may be severe. When static configuration mechanisms are failure may be severe. When static configuration mechanisms are
used, care must be taken to ensure that loops to not form. used, care must be taken to ensure that loops to not form.
3.10. Survivability 3.9. Survivability
Survivability requirements for MPLS-TP are specified in Survivability requirements for MPLS-TP are specified in
[I-D.ietf-mpls-tp-survive-fwk]. [I-D.ietf-mpls-tp-survive-fwk].
A wide variety of resiliency schemes have been developed to meet the A wide variety of resiliency schemes have been developed to meet the
various network and service survivability objectives. For example, various network and service survivability objectives. For example,
as part of the MPLS/PW paradigms, MPLS provides methods for local as part of the MPLS/PW paradigms, MPLS provides methods for local
repair using back-up LSP tunnels ([RFC4090]), while pseudowire repair using back-up LSP tunnels ([RFC4090]), while pseudowire
redundancy [I-D.ietf-pwe3-redundancy] supports scenarios where the redundancy [I-D.ietf-pwe3-redundancy] supports scenarios where the
protection for the PW can not be fully provided by the PSN layer protection for the PW can not be fully provided by the PSN layer
skipping to change at page 33, line 33 skipping to change at page 32, line 33
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 behavior. o MPLS-TP supports revertive and non-revertive behavior.
3.11. Network Management 3.10. 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-req]. It derives from the generic specified in [I-D.ietf-mpls-tp-nm-req]. It derives 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 34, line 10 skipping to change at page 33, line 10
information. For the management interface from a management system information. For the management interface from a management system
to a MPLS-TP NE, there is no restriction on which management protocol to a MPLS-TP NE, there is no restriction on which management protocol
should be used. It is used to provision and manage an end-to-end should be used. It is used to provision and manage an end-to-end
connection across a network where some segments are create/managed, connection across a network where some segments are create/managed,
for examples by Netconf or SNMP and other segments by XML or CORBA for examples by Netconf or SNMP and other segments by XML or CORBA
interfaces. Maintenance operations are run on a connection (LSP or interfaces. Maintenance operations are run on a connection (LSP or
PW) in a manner that is independent of the provisioning mechanism. PW) in a manner that is independent of the provisioning mechanism.
An MPLS-TP NE is not required to offer more than one standard An MPLS-TP NE is not required to offer more than one standard
management interface. In MPLS-TP, the EMF must be capable of management interface. In MPLS-TP, the EMF must be capable of
statically provisioning LSPs for an LSR or LER, and PWs for a PE, as statically provisioning LSPs for an LSR or LER, and PWs for a PE, as
per Section 3.9. per Section 3.8.
Fault Management (FM) functions within the EMF of an MPLS-TP NE Fault Management (FM) functions within the EMF of an MPLS-TP NE
enable the supervision, detection, validation, isolation, correction, enable the supervision, detection, validation, isolation, correction,
and alarm handling of abnormal conditions in the MPLS-TP network and and alarm handling of abnormal conditions in the MPLS-TP network and
its environment. FM must provide for the supervision of transmission its environment. FM must provide for the supervision of transmission
(such as continuity, connectivity, etc.), software processing, (such as continuity, connectivity, etc.), software processing,
hardware, and environment. Alarm handling includes alarm severity hardware, and environment. Alarm handling includes alarm severity
assignment, alarm suppression/aggregation/correlation, alarm assignment, alarm suppression/aggregation/correlation, alarm
reporting control, and alarm reporting. reporting control, and alarm reporting.
skipping to change at page 38, line 29 skipping to change at page 37, line 29
[I-D.ietf-l2vpn-arp-mediation] Rosen, E., Shah, H., Heron, G., [I-D.ietf-l2vpn-arp-mediation] Rosen, E., Shah, H., Heron, G.,
and V. Kompella, "ARP Mediation and V. Kompella, "ARP Mediation
for IP Interworking of Layer 2 for IP Interworking of Layer 2
VPN", draft-ietf-l2vpn-arp- VPN", draft-ietf-l2vpn-arp-
mediation-12 (work in progress), mediation-12 (work in progress),
June 2009. June 2009.
[I-D.ietf-mpls-tp-nm-req] Gray, E., Mansfield, S., and K. [I-D.ietf-mpls-tp-nm-req] Gray, E., Mansfield, S., and K.
Lam, "MPLS TP Network Management Lam, "MPLS TP Network Management
Requirements", Requirements",
draft-ietf-mpls-tp-nm-req-04 draft-ietf-mpls-tp-nm-req-05
(work in progress), (work in progress),
September 2009. September 2009.
[I-D.ietf-mpls-tp-oam-framework] Busi, I. and B. Niven-Jenkins, [I-D.ietf-mpls-tp-oam-framework] Busi, I. and B. Niven-Jenkins,
"MPLS-TP OAM Framework and "MPLS-TP OAM Framework and
Overview", draft-ietf-mpls-tp- Overview", draft-ietf-mpls-tp-
oam-framework-01 (work in oam-framework-01 (work in
progress), July 2009. progress), July 2009.
[I-D.ietf-mpls-tp-oam-requirements] Vigoureux, M., Ward, D., and M. [I-D.ietf-mpls-tp-oam-requirements] Vigoureux, M., Ward, D., and M.
Betts, "Requirements for OAM in Betts, "Requirements for OAM in
MPLS Transport Networks", draft- MPLS Transport Networks", draft-
ietf-mpls-tp-oam-requirements-03 ietf-mpls-tp-oam-requirements-03
(work in progress), August 2009. (work in progress), August 2009.
[I-D.ietf-mpls-tp-requirements] Niven-Jenkins, B., Brungard, D.,
Betts, M., Sprecher, N., and S.
Ueno, "MPLS-TP Requirements", dr
aft-ietf-mpls-tp-requirements-10
(work in progress), August 2009.
[I-D.ietf-mpls-tp-rosetta-stone] Helvoort, H., Andersson, L., and [I-D.ietf-mpls-tp-rosetta-stone] Helvoort, H., Andersson, L., and
N. Sprecher, "A Thesaurus for N. Sprecher, "A Thesaurus for
the Terminology used in the Terminology used in
Multiprotocol Label Switching Multiprotocol Label Switching
Transport Profile (MPLS-TP) Transport Profile (MPLS-TP)
drafts/RFCs and ITU-T's drafts/RFCs and ITU-T's
Transport Network Transport Network
Recommendations.", draft-ietf- Recommendations.", draft-ietf-
mpls-tp-rosetta-stone-00 (work mpls-tp-rosetta-stone-00 (work
in progress), June 2009. in progress), June 2009.
skipping to change at page 39, line 48 skipping to change at page 38, line 42
(work in progress), (work in progress),
September 2008. September 2008.
[I-D.ietf-pwe3-segmented-pw] Martini, L., Nadeau, T., Metz, [I-D.ietf-pwe3-segmented-pw] Martini, L., Nadeau, T., Metz,
C., Duckett, M., Bocci, M., C., Duckett, M., Bocci, M.,
Balus, F., and M. Aissaoui, Balus, F., and M. Aissaoui,
"Segmented Pseudowire", "Segmented Pseudowire",
draft-ietf-pwe3-segmented-pw-13 draft-ietf-pwe3-segmented-pw-13
(work in progress), August 2009. (work in progress), August 2009.
[RFC0826] Plummer, D., "Ethernet Address
Resolution Protocol: Or
converting network protocol
addresses to 48.bit Ethernet
address for transmission on
Ethernet hardware", STD 37,
RFC 826, November 1982.
[RFC2390] Bradley, T., Brown, C., and A.
Malis, "Inverse Address
Resolution Protocol", RFC 2390,
September 1998.
[RFC2461] Narten, T., Nordmark, E., and W.
Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC3122] Conta, A., "Extensions to IPv6
Neighbor Discovery for Inverse
Discovery Specification",
RFC 3122, June 2001.
[RFC4377] Nadeau, T., Morrow, M., Swallow, [RFC4377] Nadeau, T., Morrow, M., Swallow,
G., Allan, D., and S. G., Allan, D., and S.
Matsushima, "Operations and Matsushima, "Operations and
Management (OAM) Requirements Management (OAM) Requirements
for Multi-Protocol Label for Multi-Protocol Label
Switched (MPLS) Networks", Switched (MPLS) Networks",
RFC 4377, February 2006. RFC 4377, February 2006.
[RFC4379] Kompella, K. and G. Swallow, [RFC4379] Kompella, K. and G. Swallow,
"Detecting Multi-Protocol Label "Detecting Multi-Protocol Label
Switched (MPLS) Data Plane Switched (MPLS) Data Plane
Failures", RFC 4379, Failures", RFC 4379,
February 2006. February 2006.
[RFC5146] Kumaki, K., "Interworking [RFC5146] Kumaki, K., "Interworking
Requirements to Support Requirements to Support
Operation of MPLS-TE over GMPLS Operation of MPLS-TE over GMPLS
Networks", RFC 5146, March 2008. Networks", RFC 5146, March 2008.
[RFC5254] Bitar, N., Bocci, M., and L.
Martini, "Requirements for
Multi-Segment Pseudowire
Emulation Edge-to-Edge (PWE3)",
RFC 5254, October 2008.
[RFC5654] Niven-Jenkins, B., Brungard, D.,
Betts, M., Sprecher, N., and S.
Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654,
September 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:
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
Cisco Systems
Phone:
Fax:
EMail: danfrost@cisco.com
URI:
Lieven Levrau Lieven Levrau
Alcatel-Lucent Alcatel-Lucent
7-9, Avenue Morane Sulnier 7-9, Avenue Morane Sulnier
Velizy 78141 Velizy 78141
France France
Phone: Phone:
EMail: lieven.levrau@alcatel-lucent.com EMail: lieven.levrau@alcatel-lucent.com
Dan Frost
Cisco Systems
Phone:
Fax:
EMail: danfrost@cisco.com
URI:
 End of changes. 92 change blocks. 
343 lines changed or deleted 361 lines changed or added

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