draft-ietf-mpls-tp-framework-03.txt   draft-ietf-mpls-tp-framework-04.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 1, 2010 Cisco Systems Expires: March 15, 2010 Cisco Systems
L. Levrau L. Levrau
Alcatel-Lucent Alcatel-Lucent
August 28, 2009 D. Frost
Cisco Systems
September 11, 2009
A Framework for MPLS in Transport Networks A Framework for MPLS in Transport Networks
draft-ietf-mpls-tp-framework-03 draft-ietf-mpls-tp-framework-04
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 35 skipping to change at page 1, line 37
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 1, 2010. This Internet-Draft will expire on March 15, 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
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document specifies an architectural framework for the This document specifies an architectural framework for the
application of MPLS in transport networks. It describes a profile of application of Multi Protocol Label Switching (MPLS) in transport
MPLS that enables operational models typical in transport networks , networks, by enabling the construction of packet switched equivalents
while providing additional OAM, survivability and other maintenance to traditional circuit switched carrier networks. It describes a
functions not currently supported by MPLS. common set of protocol functions--the MPLS Transport Profile (MPLS-
TP)--that supports the operational models and capabilities typical of
such networks, including signaled or explicitly provisioned bi-
directional connection-oriented paths, protection and restoration
mechanisms, comprehensive Operations, Administration and Maintenance
(OAM) functions, and network operation in the absence of a dynamic
control plane or IP forwarding support. Some of these functions
exist in existing MPLS specifications, while others require
extensions to existing specifications to meet the requirements of the
MPLS-TP.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
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. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.3.1. MPLS Transport Profile. . . . . . . . . . . . . . . . 6
1.4.1. MPLS Transport Profile. . . . . . . . . . . . . . . . 7 1.3.2. MPLS-TP Label Switched Path . . . . . . . . . . . . . 6
1.4.2. MPLS-TP Label Switched Path . . . . . . . . . . . . . 7 1.3.3. MPLS-TP Label Switching Router and Label Edge
1.4.3. MPLS-TP PE . . . . . . . . . . . . . . . . . . . . . . 8 Router . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.4. MPLS-TP Provider Router . . . . . . . . . . . . . . . 8 1.3.4. Additional Definitions and Terminology . . . . . . . . 7
1.4.5. Additional Definitions and Terminology . . . . . . . . 8 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 8
2. Introduction to Requirements . . . . . . . . . . . . . . . . . 8 2. Introduction to Requirements . . . . . . . . . . . . . . . . . 8
3. Transport Profile Overview . . . . . . . . . . . . . . . . . . 9 3. Transport Profile Overview . . . . . . . . . . . . . . . . . . 9
3.1. Packet Transport Services . . . . . . . . . . . . . . . . 9 3.1. Packet Transport Services . . . . . . . . . . . . . . . . 9
3.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. MPLS-TP Forwarding Domain . . . . . . . . . . . . . . . . 12 3.3. MPLS-TP Forwarding Domain . . . . . . . . . . . . . . . . 15
3.4. MPLS-TP LSP Clients . . . . . . . . . . . . . . . . . . . 14 3.4. MPLS-TP LSP Clients . . . . . . . . . . . . . . . . . . . 17
3.4.1. Network Layer Transport Service . . . . . . . . . . . 14 3.4.1. Network Layer Transport Service . . . . . . . . . . . 17
3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 18 3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 21
3.6. Operations, Administration and Maintenance (OAM) . . . . . 19 3.6. Operations, Administration and Maintenance (OAM) . . . . . 22
3.7. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 23 3.7. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 26
3.8. Control Plane . . . . . . . . . . . . . . . . . . . . . . 26 3.8. Control Plane . . . . . . . . . . . . . . . . . . . . . . 29
3.8.1. PW Control Plane . . . . . . . . . . . . . . . . . . . 28 3.8.1. PW Control Plane . . . . . . . . . . . . . . . . . . . 31
3.8.2. LSP Control Plane . . . . . . . . . . . . . . . . . . 28 3.8.2. LSP Control Plane . . . . . . . . . . . . . . . . . . 31
3.9. Static Operation of LSPs and PWs . . . . . . . . . . . . . 29 3.9. Static Operation of LSPs and PWs . . . . . . . . . . . . . 32
3.10. Survivability . . . . . . . . . . . . . . . . . . . . . . 29 3.10. Survivability . . . . . . . . . . . . . . . . . . . . . . 32
3.11. Network Management . . . . . . . . . . . . . . . . . . . . 30 3.11. Network Management . . . . . . . . . . . . . . . . . . . . 33
4. Security Considerations . . . . . . . . . . . . . . . . . . . 31 4. Security Considerations . . . . . . . . . . . . . . . . . . . 34
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.1. Normative References . . . . . . . . . . . . . . . . . . . 32 7.1. Normative References . . . . . . . . . . . . . . . . . . . 35
7.2. Informative References . . . . . . . . . . . . . . . . . . 35 7.2. Informative References . . . . . . . . . . . . . . . . . . 38
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 [I-D.ietf-mpls-tp-requirements] and
what new protocol elements are required. what new protocol elements are required.
Bandwidth demand continues to grow worldwide, stimulated by the Historically the optical transport infrastructure (Synchronous
accelerating growth and penetration of new packet based services and Optical Networking (SONET)/Synchronous Digital Hierarchy (SDH),
multimedia applications: Optical Transport Network (OTN)) has provided carriers with a high
benchmark for reliability and operational simplicity. To achieve
o Packet-based services such as Ethernet, Voice over IP (VoIP), this transport technologies have been designed with specific
Layer 2 (L2)/Layer 3 (L3) Virtual Private Networks (VPNs), IP characteristics :
Television (IPTV), Radio Access Network (RAN) back-hauling, etc.,
o Applications with various bandwidth and Quality of Service (QoS)
requirements.
This growth in demand has resulted in dramatic increases in access
rates that are, in turn, driving dramatic increases in metro and core
network bandwidth requirements.
Over the past two decades, the evolving optical transport
infrastructure (Synchronous Optical Networking (SONET)/Synchronous
Digital Hierarchy (SDH), Optical Transport Network (OTN)) has
provided carriers with a high benchmark for reliability and
operational simplicity. To achieve this, these existing transport
technologies have been designed with specific 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.
o A high level of protection and availability. o A high level of protection and availability.
o Quality of service. o Quality of service.
o Extended OAM capabilities. o Extended OAM capabilities.
Carriers are looking to evolve such transport networks to support Carriers wish to evolve such transport networks to support packet
packet based services and networks, and to take advantage of the based services and networks, and to take advantage of the flexibility
flexibility and cost benefits of packet switching technology. While and cost benefits of packet switching technology. While MPLS is a
MPLS is a maturing packet technology that is already playing an maturing packet technology that is already playing an important role
important role in transport networks and services, not all of MPLS's in transport networks and services, not all of MPLS's capabilities
capabilities and mechanisms are needed and/or consistent with and mechanisms are needed and/or consistent with transport network
transport network operations. There are also transport technology operations. There are also transport technology characteristics that
characteristics that are not currently reflected in MPLS. are not currently reflected in MPLS.
The types of packet transport services delivered by transport The types of packet transport services delivered by transport
networks are very similar to Layer 2 Virtual Private Networks defined networks are very similar to Layer 2 Virtual Private Networks defined
by the IETF. by the IETF.
There are thus two objectives for MPLS-TP: There are thus two objectives for MPLS-TP:
1. To enable MPLS to be deployed in a transport network and operated 1. To enable MPLS to be deployed in a transport network and operated
in a similar manner to existing transport technologies. in a similar manner to existing transport technologies.
skipping to change at page 5, line 32 skipping to change at page 5, line 18
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. An equipment conforming to MPLS-TP MUST support this
profile. An MPLS-TP conformant equipment MAY support additional MPLS profile. An MPLS-TP conformant equipment MAY support additional MPLS
features. A carrier may deploy some of those additional features in features. A carrier may deploy some of those additional features in
the transport layer of their network if they find them to be the transport layer of their network if they find them to be
beneficial. beneficial.
1.2. Applicability 1.2. Scope
Figure 1 illustrates the range of services that MPLS-TP is intended
to address. MPLS-TP is intended to support a range of layer 1, layer
2 and layer 3 services, and is not limited to layer 3 services only.
Networks implementing MPLS-TP may choose to only support a subset of
these services.
MPLS-TP Solution exists
over this spectrum
|<-------------------------->|
cl-ps Multi-Service co-cs & co-ps
(cl-ps & co-ps) (Label is
| | service context)
| | |
|<--------------------------|--------------------------->|
| | |
L3 Only L1, L2, L3 Services L1, L2 Services
Pt-Pt, Pt-MP, MP-MP Pt-Pt and Pt-MP
Figure 1: MPLS-TP Applicability
The diagram above shows the spectrum of services that can be
supported by MPLS. MPLS-TP solutions are primarily intended for
packet transport applications. These can be deployed using a profile
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),
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-
service solution in the centre of the figure.
1.3. Scope
This document describes a framework for a Transport Profile of This document describes a framework for a Transport Profile of
Multiprotocol Label Switching (MPLS-TP). It presents the Multiprotocol Label Switching (MPLS-TP). It presents the
architectural framework for MPLS-TP, defining those elements of MPLS architectural framework for MPLS-TP, defining those elements of MPLS
applicable to supporting the requirements in applicable to supporting the requirements in
[I-D.ietf-mpls-tp-requirements] and what new protocol elements are [I-D.ietf-mpls-tp-requirements] and what new protocol elements are
required. required.
This document describes the architecture for MPLS-TP when the LSP 1.3. Terminology
client is a pseudowire, and when the LSP is providing a network layer
transport service.
1.4. 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
cl-ps Connectionless - Packet Switched cl-ps Connectionless - Packet Switched
co-cs Connection Oriented - Circuit Switched co-cs Connection Oriented - Circuit Switched
skipping to change at page 7, line 32 skipping to change at page 6, line 32
APS Automatic Protection Switching APS Automatic Protection Switching
SCC Signaling Communication Channel SCC Signaling Communication Channel
MCC Management Communication Channel MCC Management Communication Channel
EMF Equipment Management Function EMF Equipment Management Function
FM Fault Management FM Fault Management
CM Configuration Management CM Configuration Management
PM Performance Management PM Performance Management
LSR Label 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
1.4.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]. that meet the requirements in [I-D.ietf-mpls-tp-requirements]. Note
that MPLS is defined to include any present and future MPLS
capability specified by the IETF, include those capabilities
specifically added to support the transport network requirement
[I-D.ietf-mpls-tp-requirements].
1.4.2. MPLS-TP Label Switched Path 1.3.2. MPLS-TP Label Switched Path
An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that conforms An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that uses a
to a subset of the capabilities of an MPLS LSP. Specifically, it is subset of the capabilities of an MPLS LSP in order to meet the
an MPLS LSP that is used in an MPLS transport network as defined by requirements of an MPLS transport network as set out in
this document to meet the requirements set out in
[I-D.ietf-mpls-tp-requirements]. The characteristics of an MPLS-TP [I-D.ietf-mpls-tp-requirements]. 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.
1.4.3. MPLS-TP PE 5. LSPs can only be point to point or point to multipoint, i.e. the
merging of LSPs is not permitted.
An MPLS-TP Provider Edge (MPLS-TP PE) is an MPLS-TP LSR that adapts Note that an MPLS LSP is defined to include any present and future
client traffic and encapsulate it to be carried over an MPLS-TP LSP. MPLS capability include those specifically added to support the
Encapsulation may be as simple as pushing a label, or it may require transport network requrements.
the use of a pseudowire. An MPLS-TP PE exists at the interface
between a pair of layer networks.
1.4.4. MPLS-TP Provider Router 1.3.3. MPLS-TP Label Switching Router and Label Edge Router
An MPLS-TP Provider router (MPLS-TP P Router) is an MPLS-TP LSR that An MPLS-TP Label Switching Router (MPLS-TP LSR) is either an MPLS-TP
does not provide MPLS-TP PE functionality. An MPLS-TP P router Provider Edge (MPLS-TP PE) or an MPLS-TP Provider (MPLS-TP P Router)
switches LSPs which carry client traffic, but do not adapt the client router as defined below. The terms MPLS-TP PE and MPLS-TP P router
traffic and encapsulate it to be carried over an MPLS-TP LSP. describe functions and specific node may undertake both roles. Note
that the use of the term "router" in this context is historic and
neither requires nor precludes the ability to perform IP forwarding.
Note that the use of the term "router" in this context is historic 1.3.3.1. MPLS-TP Provider Edge Router
and neither requires nor precludes the ability to perform IP
forwarding.
1.4.5. Additional Definitions and Terminology An MPLS-TP Provider Edge is an MPLS-TP LSR that adapts client traffic
and encapsulate it to be carried over an MPLS-TP LSP. Encapsulation
may be as simple as pushing a label, or it may require the use of a
pseudowire. An MPLS-TP PE exists at the interface between a pair of
layer networks.
A layer network is defined in [I-D.ietf-mpls-tp-rosetta-stone].
1.3.3.2. MPLS-TP Provider Router
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
carry client traffic, but do not adapt the client traffic and
encapsulate it to be carried over an MPLS-TP LSP.
1.3.4. 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]. [I-D.ietf-mpls-tp-requirements].
1.4. Applicability
MPLS-TP can be used to construct a packet transport networks and is
therefore applicable in any packet transport network application. It
is also as an alternative architecture for subsets of a packet
network where the transport network model is deemed attractive.
These two modes can be considered vertical and horizontal
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
service for an IP network; in the second mode it is viewed as part of
the IP/MPLS network and peers/interconnects directly to it. These
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
[I-D.ietf-mpls-tp-requirements], [I-D.ietf-mpls-tp-oam-requirements], [I-D.ietf-mpls-tp-requirements], [I-D.ietf-mpls-tp-oam-requirements],
and [I-D.ietf-mpls-tp-nm-req]. This section provides a brief and [I-D.ietf-mpls-tp-nm-req]. This section provides a brief
reminder to guide the reader. It is not intended as a substitute for reminder to guide the reader. It is 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
skipping to change at page 10, line 11 skipping to change at page 9, line 44
o The complete set of packets generated by a client MPLS(-TP) layer o The complete set of packets generated by a client MPLS(-TP) layer
network using the packet transport service, which may contain network using the packet transport service, which may contain
packets that are not MPLS packets (e.g. IP or CNLS packets used packets that are not MPLS packets (e.g. IP or CNLS packets used
by the control/management plane of the client MPLS(-TP) layer by the control/management plane of the client MPLS(-TP) layer
network), are transported by the MPLS-TP server layer network. network), are transported by the MPLS-TP server layer network.
o The packet transport service enables the MPLS-TP layer network o The packet transport service enables the MPLS-TP layer network
addressing and other information (e.g. topology) to be hidden from addressing and other information (e.g. topology) to be hidden from
any client layer networks using that service, and vice-versa. any client layer networks using that service, and vice-versa.
Figure 1 illustrates the range of services that MPLS-TP is intended
to address. MPLS-TP is intended to support a range of layer 1, layer
2 and layer 3 services, and is not limited to layer 3 services only.
Networks implementing MPLS-TP may choose to only support a subset of
these services.
MPLS-TP Solution exists
over this spectrum
|<-------------------------->|
cl-ps Multi-Service co-cs & co-ps
(cl-ps & co-ps) (Label is
| | service context)
| | |
|<--------------------------|--------------------------->|
| | |
L3 Only L1, L2, L3 Services L1, L2 Services
Pt-Pt, Pt-MP, MP-MP Pt-Pt and Pt-MP
Figure 1: Packet Transport Service Characteristics
The diagram above shows the spectrum of services that can be
supported by MPLS. MPLS-TP solutions are primarily intended for
packet transport applications. These can be deployed using a profile
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),
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-
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 [Editors' Note Section 3.2 needs to generalized to include the
architecture when PWs are not being transported and the client is IP, 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 MPLS or a network layer service over MPLS-TP LSPs as described in
section 3.4] section 3.4]
EDITOR'S NOTE Comment received from Dan Frost that we need to
address:
========
- Sections 3.2 (Architecture) - 3.4 (MPLS-TP Forwarding Domain)
The organisation of these sections is confusing. It appears as if
the current content of Sec. 3.2 should be relocated to a new Sec.
3.4.1 (MPLS-TP PW Client), making the current 3.4.1 become 3.4.2, and
be trimmed accordingly.
A new Sec. 3.2 on the overall architecture can then be written, which
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 definition applies to the following two domains:
o MPLS-TP Forwarding Domain
o MPLS-TP Transport Domain
Neither term is defined. The first appears only as the name of the
next subsection, while the second appears only in the text at the
beginning of Section 3.4. As well as proper definitions, there's
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)
In a previous comment it was suggested to relocate the current
content of Section 3.2 to a new PW subsection of Section 3.4.
Following are the items it would be nice to see in a new Section 3.2
covering the overall architecture:
- summary of the device roles in an MPLS-TP network (CE, PE, P) -
summary of the principal transport entities in an MPLS-TP network:
Sections, LSPs (list/describe different types), PWs - summary of
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)
=========
The architecture for a transport profile of MPLS (MPLS-TP) that uses The architecture for a transport profile of MPLS (MPLS-TP) that uses
PWs is based on the MPLS [RFC3031], pseudowire [RFC3985], and multi- PWs is based on the MPLS [RFC3031], pseudowire [RFC3985], and multi-
segment pseudowire [I-D.ietf-pwe3-ms-pw-arch] architectures, as segment pseudowire [I-D.ietf-pwe3-ms-pw-arch] architectures, as
illustrated in Figure 2. illustrated in Figure 3.
EDITORS'S NOTE - WE HAVE MODIFIED THE FIGS BELOW TO INCLUDE P ROUTERS
AND HAVE ADDED THE IP/MPLS LSP CASE. WE NEED TO REWRITE THE TEXT IN
THIS SECTION TO ALIGN WITH THE CONTENTS OF THE FIGURES.
|<--------------- Client Service ----------------->|
| |
| |<---- Pkt Xport Service --->|
| | | |
| | |<-- 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
|<-------------- Emulated Service ---------------->| |<-------------- Emulated Service ---------------->|
| | | |
| |<------- Pseudowire ------->| | | |<------- Pseudowire ------->| |
| | encapsulated | |
| | Pkt Xport Service | |
| | | | | | | |
| | |<-- PSN Tunnel -->| | | | | |<-- PSN Tunnel -->| | |
| V V V V | | V V V V |
V AC +----+ +----+ AC V V AC +----+ +---+ +----+ AC V
+-----+ | | PE1|==================| PE2| | +-----+ +-----+ | | PE1|======:=X=:=======| PE2| | +-----+
| |----------|............PW1.............|----------| | | |----------|...........:PW1:............|----------| |
| CE1 | | | | | | | | CE2 | | CE1 | | | | | : | | | | CE2 |
| |----------|............PW2.............|----------| | | |----------|...........:PW2:............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+ +-----+ ^ | | |======:=X=:=======| | | ^ +-----+
^ | +----+ +----+ | | ^ ^ | +----+ +---+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | | | | Provider Edge 1 ^ Provider Edge 2 | |
| | | | | | | | |
Customer | | Customer Customer | P Router | Customer
Edge 1 | | Edge 2 Edge 1 | | Edge 2
| | | |
| | | |
Native service Native service Native service Native service
Figure 2: MPLS-TP Architecture (Single Segment PW) Figure 3: MPLS-TP Architecture (Single Segment PW)
Native |<------------Pseudowire-------------->| Native
Service | PSN PSN | Service |<------------Pseudowire-------------->|
(AC) | |<--cloud->| |<-cloud-->| | (AC) | encapsulated |
| Pkt Xport Service |
| |
| PSN PSN |
AC | |<--tun1->| |<--tun2--->| | AC
| V V V V V V | | V V V V V V |
| +----+ +-----+ +----+ | | +----+ +-----+ +----+ |
+----+ | |TPE1|===========|SPE1 |==========|TPE2| | +----+ +----+ | |TPE1|===========|SPE1 |==========|TPE2| | +----+
| |------|..... PW.Seg't1....X....PW.Seg't3.....|-------| | | |------|..... PW.Seg't1....X....PW.Seg't3.....|-------| |
| 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 |
skipping to change at page 11, line 22 skipping to change at page 14, line 4
| |------|..... 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) MPLS-TP Architecture (Multi-Segment PW)
The above figures illustrates the MPLS-TP architecture used to The above figures illustrates the MPLS-TP architecture used to
provide a point-to-point packet transport service, or VPWS. In this 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 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 SS-PW or MS-PW forwarding architecture as detailed in section
Section 3.3. 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 This document describes the architecture for MPLS-TP when the LSP
client is a PW. The transport of IP and MPLS, other than carried 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 over a PW, is outside the scope of this document. This does not
preclude the use of LSPs conforming to the MPLS transport profile preclude the use of LSPs conforming to the MPLS transport profile
from being used to carry IP or other MPLS LSPs by general purpose 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, 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. so that more than one LSP label MAY appear in the label stack.
+---------------------------+ +---------------------------+
| Native service | | 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 |
+---------------------------+
Figure 4: Domain of MPLS-TP Layer Network for IP and LSP Clients
+---------------------------+
| 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 3: Domain of MPLS-TP Layer Network using Pseudowires Figure 5: Domain of MPLS-TP Layer Network using Pseudowires
Figure (Figure 3) illustrates the protocol stack to be used when Figure (Figure 5) illustrates the protocol stack to be used when
pseudowires are carried over MPLS-TP LSPs. pseudowires are carried over MPLS-TP LSPs.
When providing a VPWS, VPLS, VPMS or IPLS, pseudowires MUST be used When providing a VPWS, VPLS, VPMS or IPLS, pseudowires MUST be used
to carry a client service. For compatibility with transport to carry a client service. For compatibility with transport
nomenclature, the PW may be referred to as the MPLS-TP Channel and nomenclature, the PW may be referred to as the MPLS-TP Channel and
the LSP may be referred to as the MPLS-TP Path. the LSP may be referred to as the MPLS-TP Path.
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.
skipping to change at page 14, line 35 skipping to change at page 17, line 35
When the client is a PW, the MPLS-TP transport domain consists of the When the client is a PW, the MPLS-TP transport domain consists of the
PW encapsulation mechanisms, including the PW control word. When the PW encapsulation mechanisms, including the PW control word. When the
client is operating at the network layer the mechanism described in client is operating at the network layer the mechanism described in
Section 3.4.1 is used. Section 3.4.1 is used.
3.4.1. Network Layer Transport Service 3.4.1. Network Layer Transport Service
MPLS-TP LSPs can be used to deliver a network level transport MPLS-TP LSPs can be used to deliver a network level transport
service. Such a network layer transport service (NLTS) can be used service. Such a network layer transport service (NLTS) can be used
to transport any network layer protocol between service interfaces. to transport any network layer protocol between service interfaces.
Example of network layer protocols include IP, MPLS and even MPLS-TP. 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) MPLS-TP nodes. Point-to- multipoint service is for further
study. As shown in Figure 4, there is an attachment circuit between study. As shown in Figure 6, there is an attachment circuit between
the CE node on the left and its corresponding provider edge (PE) node the CE node on the left and its corresponding provider edge (PE) node
that provides the service interface, a bidirectional LSP across the that provides the service interface, a bidirectional LSP across the
MPLS-TP service network to the corresponding PE node on the right, MPLS-TP service network to the corresponding PE node on the right,
and an attachment circuit between that PE node and the corresponding and an attachment circuit between that PE node and the corresponding
CE node for this service. CE node for this service.
: +--------------------+ : : +--------------------+ :
: | +------------+ | : : | +------------+ | :
: | | Management | | : : | | Management | | :
+------+ : | | system(s) | | : +------+ +------+ : | | system(s) | | : +------+
skipping to change at page 15, line 43 skipping to change at page 18, 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 4: Network Layer Transport Service Components Figure 6: 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 carry 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 L1/L2 encoding defined for that service interface encapsulated in the Layer1/Layer2 encoding defined
access link type. It should be noted that the set of network layer for that access link type. It should be noted that the set of
protocols includes MPLS and hence MPLS encoded packets with an MPLS network layer protocols includes MPLS and hence MPLS encoded packets
label stack (the client MPLS stack), may appear at the service with an MPLS label stack (the client MPLS stack), may appear at the
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 5 shows how an a client layer protocol being transported. Figure 7 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 5: Network Layer Transport Service Protocol Stack Figure 7: 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 5. The mapping between Labels", one of which is shown in Figure 7. 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 5. The use of an edge-to-edge LSP LSP, which is also shown in Figure 7. 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 19, line 24 skipping to change at page 22, line 35
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 6 ). The MEPs Maintenance End Points (MEPs) (see example in Figure 8 ). 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 20, line 28 skipping to change at page 23, 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 6: Example of MPLS-TP OAM Figure 8: Example of MPLS-TP OAM
Figure 7 illustrates how the concept of Maintenance Entities can be Figure 9 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 21, line 36 skipping to change at page 24, 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 7: MPLS-TP OAM archtecture Figure 9: 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 24, line 36 skipping to change at page 27, 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 8 shows the reference model depicting how the control channel Figure 10 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 25, line 27 skipping to change at page 28, line 27
| | | |
| ____ ___ ____ | | ____ ___ ____ |
| _/ \___/ \ _/ \__ | | _/ \___/ \ _/ \__ |
| / \__/ \_ | | / \__/ \_ |
| / \ | | / \ |
+--------| MPLS/MPLS-TP Network |---+ +--------| MPLS/MPLS-TP Network |---+
\ / \ /
\ ___ ___ __ _/ \ ___ ___ __ _/
\_/ \____/ \___/ \____/ \_/ \____/ \___/ \____/
Figure 8: PWE3 Protocol Stack Reference Model including the G-ACh Figure 10: 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 9 shows the reference model depicting how the control channel Figure 11 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 26, line 26 skipping to change at page 29, line 26
| | | |
| ____ ___ ____ | | ____ ___ ____ |
| _/ \___/ \ _/ \__ | | _/ \___/ \ _/ \__ |
| / \__/ \_ | | / \__/ \_ |
| / \ | | / \ |
+--------| MPLS/MPLS-TP Network |---+ +--------| MPLS/MPLS-TP Network |---+
\ / \ /
\ ___ ___ __ _/ \ ___ ___ __ _/
\_/ \____/ \___/ \____/ \_/ \____/ \___/ \____/
Figure 9: MPLS Protocol Stack Reference Model including the LSP Figure 11: MPLS Protocol Stack Reference Model including the LSP
Associated Control Channel Associated Control Channel
3.8. Control Plane 3.8. 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
[I-D.ietf-mpls-tp-requirements] can be met, the MPLS transport [I-D.ietf-mpls-tp-requirements] can be met, the MPLS transport
profile uses existing control plane protocols for LSPs and PWs. profile uses existing control plane protocols for LSPs and PWs.
Figure 10 illustrates the relationship between the MPLS-TP control Figure 12 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 27, line 32 skipping to change at page 30, 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 10: MPLS-TP Control Plane Architecture Context Figure 12: 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 35, line 19 skipping to change at page 38, line 19
Channel", RFC 5586, June 2009. Channel", RFC 5586, June 2009.
7.2. Informative References 7.2. Informative References
[I-D.ietf-bfd-mpls] Aggarwal, R., Kompella, K., [I-D.ietf-bfd-mpls] Aggarwal, R., Kompella, K.,
Nadeau, T., and G. Swallow, "BFD Nadeau, T., and G. Swallow, "BFD
For MPLS LSPs", For MPLS LSPs",
draft-ietf-bfd-mpls-07 (work in draft-ietf-bfd-mpls-07 (work in
progress), June 2008. progress), June 2008.
[I-D.ietf-mpls-tp-nm-req] Mansfield, S. and K. Lam, "MPLS [I-D.ietf-l2vpn-arp-mediation] Rosen, E., Shah, H., Heron, G.,
TP Network Management and V. Kompella, "ARP Mediation
for IP Interworking of Layer 2
VPN", draft-ietf-l2vpn-arp-
mediation-12 (work in progress),
June 2009.
[I-D.ietf-mpls-tp-nm-req] Gray, E., Mansfield, S., and K.
Lam, "MPLS TP Network Management
Requirements", Requirements",
draft-ietf-mpls-tp-nm-req-02 draft-ietf-mpls-tp-nm-req-04
(work in progress), June 2009. (work in progress),
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-02 ietf-mpls-tp-oam-requirements-03
(work in progress), June 2009. (work in progress), August 2009.
[I-D.ietf-mpls-tp-requirements] Niven-Jenkins, B., Brungard, D., [I-D.ietf-mpls-tp-requirements] Niven-Jenkins, B., Brungard, D.,
Betts, M., Sprecher, N., and S. Betts, M., Sprecher, N., and S.
Ueno, "MPLS-TP Requirements", dr Ueno, "MPLS-TP Requirements", dr
aft-ietf-mpls-tp-requirements-10 aft-ietf-mpls-tp-requirements-10
(work in progress), August 2009. (work in progress), August 2009.
[I-D.ietf-mpls-tp-rosetta-stone] Helvoort, H., Andersson, L., and
N. Sprecher, "A Thesaurus for
the Terminology used in
Multiprotocol Label Switching
Transport Profile (MPLS-TP)
drafts/RFCs and ITU-T's
Transport Network
Recommendations.", draft-ietf-
mpls-tp-rosetta-stone-00 (work
in progress), June 2009.
[I-D.ietf-mpls-tp-survive-fwk] Sprecher, N., Farrel, A., and H. [I-D.ietf-mpls-tp-survive-fwk] Sprecher, N., Farrel, A., and H.
Shah, "Multiprotocol Label Shah, "Multiprotocol Label
Switching Transport Profile Switching Transport Profile
Survivability Framework", draft- Survivability Framework", draft-
ietf-mpls-tp-survive-fwk-00 ietf-mpls-tp-survive-fwk-00
(work in progress), April 2009. (work in progress), April 2009.
[I-D.ietf-pwe3-dynamic-ms-pw] Martini, L., Bocci, M., Bitar, [I-D.ietf-pwe3-dynamic-ms-pw] Martini, L., Bocci, M., Bitar,
N., Shah, H., Aissaoui, M., and N., Shah, H., Aissaoui, M., and
F. Balus, "Dynamic Placement of F. Balus, "Dynamic Placement of
skipping to change at page 37, line 13 skipping to change at page 40, line 27
Networks", RFC 5146, March 2008. Networks", RFC 5146, March 2008.
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: +44-207-254-5874 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: +44-208-824-8828 Phone:
EMail: stbryant@cisco.com EMail: stbryant@cisco.com
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: +33-6-33-86-1916 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. 62 change blocks. 
175 lines changed or deleted 324 lines changed or added

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