Internet DRAFT - draft-martinotti-mpls-unified-mpls-fwk
draft-martinotti-mpls-unified-mpls-fwk
Network Working Group L. Andersson
Internet-Draft R. Martinotti
Intended status: Standards Track Ericsson
Expires: July 28, 2012 January 25, 2012
"Unified MPLS Framework"
draft-martinotti-mpls-unified-mpls-fwk-01.txt
Abstract
This document is framework for Unified MPLS.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 28, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Andersson & Martinotti Expires July 28, 2012 [Page 1]
Internet-Draft Unified MPLS Framework January 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation and Background . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1. MPLS Protocols and Packages . . . . . . . . . . . . . 5
1.3.2. MPLS Technology . . . . . . . . . . . . . . . . . . . 6
1.3.3. Topology Driven MPLS . . . . . . . . . . . . . . . . . 6
1.3.4. MPLS Traffic Engineering . . . . . . . . . . . . . . . 6
1.3.5. MPLS Transport Profile . . . . . . . . . . . . . . . . 7
1.3.6. Additional Terms and Acronyms . . . . . . . . . . . . 7
1.3.7. MPLS Terminology structure . . . . . . . . . . . . . . 8
2. Unified MPLS Requirements . . . . . . . . . . . . . . . . . . 13
2.1. Full Interoperability and Interworking . . . . . . . . . . 13
2.2. Common Data Plane . . . . . . . . . . . . . . . . . . . . 13
2.3. Common OAM . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4. Data Plane Agnostic . . . . . . . . . . . . . . . . . . . 13
2.5. Interworking . . . . . . . . . . . . . . . . . . . . . . . 13
3. Unified MPLS Overview . . . . . . . . . . . . . . . . . . . . 15
3.1. Unified MPLS Control Plane . . . . . . . . . . . . . . . . 15
3.2. Unified MPLS Data Plane . . . . . . . . . . . . . . . . . 15
3.3. Unified MPLS Management . . . . . . . . . . . . . . . . . 16
3.4. Unified MPLS OAM . . . . . . . . . . . . . . . . . . . . . 17
4. Interfaces and Interworking . . . . . . . . . . . . . . . . . 18
4.1. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Network Layer Interworking . . . . . . . . . . . . . . . . 18
4.3. Service Layer Interworking . . . . . . . . . . . . . . . . 18
4.4. Network Overlay . . . . . . . . . . . . . . . . . . . . . 19
5. MPLS Resiliency . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. MPLS Recovery . . . . . . . . . . . . . . . . . . . . . . 20
5.2. MPLS Protection . . . . . . . . . . . . . . . . . . . . . 20
5.3. MPLS Survivability . . . . . . . . . . . . . . . . . . . . 20
6. Other Unified MPLS Considerations . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
10.2. Informative references . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Andersson & Martinotti Expires July 28, 2012 [Page 2]
Internet-Draft Unified MPLS Framework January 2012
1. Introduction
The term "Unified MPLS" indicates several different things:
The ambition to continue to keep MPLS together as one single
technology, base on a common architecture.
The ambition to maximize interworking between different flavors of
MPLS (MPLS Packages) within the MPLS technology
The ambition that functionality developed for one of the MPLS
Aggregate Packages should be re-useable within other MPLS Aggregate
Packages,
MPLS is a mature Internet technology that has been used over the last
18 years to give e.g. QoS, resiliency, scalability, virtualization,
etc. to IP networks.
Through e.g. Pseudowires and L2VPN development it has also been
adapted to emulate legacy protocols such as Frame Relay, TDM, ATM and
Ethernet.
The development of the MPLS technology has been very rapid since the
start, the last 4 to 5 years have not been an exception. In
particular we have seen developments in OAM in order to meet
transport environments requirements, specification of multicast
techniques and over the last years new resiliency strategies have
been deployed.
Over the years it has become possible to distinguish different MPLS
Packages, e.g.MPLS traffic Engineering (MPLS-TE), Topology Driven
MPLS (MPLS-TD) and the Transport Profile of MPLS (MPLS-TP).
Revision note: Version -01 has been updated after comments from
several sources, especial we are grateful for comments tht has helped
improve the structure of the document. We have als recieved comment
to the effect "in the list in (now) section 1.3 you have missed" we
have tried aqdd this information as best as we can.
There is still some glaring holes that we need to cover and is open
to input and participation driving the draft forward.
1.1. Motivation and Background
Needless to say this very dynamic environment has put stress on the
MPLS architecture. Another factor that contributed is that MPLS
technology over the years has evolved to addresses almost all
networking market segments.
Andersson & Martinotti Expires July 28, 2012 [Page 3]
Internet-Draft Unified MPLS Framework January 2012
Vendors that are only interested to incorporate one of the MPLS
packages often tend to prioritize the development of one of the
packages at the expense of the others, one typical example is the
T-MPLS standardization that was started within ITU-T and rapidly
developed into a separate technology. This in itself put stress on
the MPLS architecture.
The MPLS architecture has stood up surprisingly well, but there are a
few things that need to be documented as part of the MPLS
architecture, primarily on the OAM side, but also on MPLS multicast
and traffic engineering.
The time has come to take steps to bring the MPLS architecture
together and create a unified MPLS architecture - an architecture and
protocol suite that can operate end to end, with pieces that may be
combined in a fashion that can meet the needs of the service provider
according to their requirements and environment and not the
limitations of the profiles.
1.2. Scope
The term "Unified MPLS" has come to indicate that the environment
where MPLS is used has been gradually changing over the years, it is
highly likely that architectural updates are needed. This framework
document addresses how the environment of RFC 3031 [RFC3031]has
changed. MPLS started out as a set of tools to support IP networks,
but over time developed to have much broader application than that.
We have seen the development of IP-VPNs, L2VPNs, PWs for carrying
non-IP payload, deployment of MPLS in networks where we don't even
require or have IP in the forwarding plane.
Starting with existing MPLS protocols, i.e. data plane, signaling
(label distribution) protocols, routing, TE-extensions, OAM and the
different management tools it is possible to build a surprisingly
large number of viable MPLS deployments.
For lack of a better name we have chosen to call the deployable MPLS
constructs "packages". In Terminology (Section 1.3) we will
elaborate on this terminology.
This document discusses interworking between MPLS Packages on LSP
level. Discussion of interworking between PWs is for further study.
A number of standardization and technology development projects have
extended MPLS in very different directions. In Unified MPLS we make
two assumptions:
Andersson & Martinotti Expires July 28, 2012 [Page 4]
Internet-Draft Unified MPLS Framework January 2012
1. The Interworking potential between different MPLS Packages and
MPLS Aggregate packages shall be maximized and that this is a
design goal in all development and standardization of MPLS.
2. Functionality developed for one MPLS Aggregate Package, e.g. the
MPLS-TP OAM tools developed in the joint project with ITU-T,
shall be designed in such a way that it is re-useable within
other MPLS (Aggregate) Packages.
1.3. Terminology
In the "ontology" section (Section 1.3.7) an outline of this aspect
of the MPLS terminology is given.
1.3.1. MPLS Protocols and Packages
For the purpose of understanding the MPLS terminology structure we
operate with four concepts; MPLS Protocols, MPLS Packages, MPLS
Aggregate Packages and MPLS Technology.
1.3.1.1. MPLS Protocols
We have a rather wide definition of "protocol", i.e. all the IETF
protocols that specify MPLS behavior of the data, control and
management plane. OAM is considered to be part of the data plane.
1.3.1.2. MPLS Packages
An MPLS Package is a ordered collection of MPLS protocols put
together because it can give you a desired functionality. One
example would be running OSPF and LDP in your network to create a
topology driven MPLS see Topology Driven MPLS (Section 1.3.3).
1.3.1.3. MPLS Aggregate Packages
An MPLS Aggregate Package is a grouping of MPLS Packages. Packages
that can be used to build MPLS network of identical functionality can
be grouped into MPLS Aggregate Package. There is for example nothing
that stops you from running Topology Driven MPLS (MPLS-TD) based on
ISIS instead of OSPF; those two MPLS packages form together the
MPLS-TD Aggregate package.
Note: We need to revisit "identical functionality" in the paragraph
above and see if there is a better way do describe this.
We see that it is possible to form three different MPLS Aggregate
Packages. First we have MPLS Traffic Engineering (MPLS-TE), Topology
Driven MPLS (MPLS-TD) and the MPLS Transport Profile (MPLS-TP).
Andersson & Martinotti Expires July 28, 2012 [Page 5]
Internet-Draft Unified MPLS Framework January 2012
In - whichever section it will be - a somewhat simplified overview of
MPLS Protocols, Packages and Aggregate Packages.
1.3.2. MPLS Technology
The "MPLS" or "MPLS Technology" is a the sum of the MPLS protocols
and the method of grouping them to MPLS Packages and Aggregate MPLS
Packages as illustrated in the - Appendix.
The MPLS technology is also scoped, described and explained in a
number of documents; such as applicability statements, requirements
and frameworks. Though those document are not part of the Standards
Track they are important as they gives a comprehensive view of the
MPLS Technology.
1.3.3. Topology Driven MPLS
We talk about Topology Driven MPLS (MPLS-TD) when the protocols
establishing LSPs are limited to use the topology information created
by IP routing protocols; i.e. packets sent over an MPLS LSP will
traverse the network over the same path as it would have taken if the
Shortest Path IP forwarding had been used.
MPLS-TD consist of at least two different MPLS Packages, depending if
ISIS or OSPF is used as the routing protocol. LDP is almost the only
signaling protocol that is used in this type of network.
Note: It is technically possible to use other routing protocols, e.g.
Routing Information Protocol (RIP) RFC 2453 [RFC2453] or even static
configuration or routes. However use of RIP or static routes in MPLS
is very limited, and for all practical purposes these cases can be
left aside.
1.3.4. MPLS Traffic Engineering
We talk about MPLS Traffic Engineering (MPLS-TE) when other
parameters than just the shortest path is taken into consideration
when deciding on how and where an LSP should be set up. By far the
most common criteria are available BW and explicit routing, this
explains why the RSVP-TE protocol was well suited to be adapted as
MPLS-TE signaling protocol.
Deciding how many MPLS-TE Packages there are is slightly harder than
for the MPLS-TD.
There are two and only two routing protocols - OSPF-TE and ISIS-TE.
For the signaling protocols the situation is a bit ambivalent; the
Andersson & Martinotti Expires July 28, 2012 [Page 6]
Internet-Draft Unified MPLS Framework January 2012
MPLS developed a RSVP-TE for MPLS traffic engineering RFC 3209
[RFC3209]. When the RSVP-TE was "generalized" for Generalized MPLS
(GMPLS) the intention was that the more specific objects should be
possible to use, but for the Label object this was never achieved.
One could therefore say that we have two different signaling
protocols.
1.3.5. MPLS Transport Profile
The MPLS Transport Profile (MPLS-TP) is the latest addition of the
MPLS Aggregate Packages. It is an extension of MPLS to meet the
requirements from transport networks.
There are five different MPLS Packages for MPLS-TP
Note: We have a comment that we also have a hybrid package, when both
an NMS and and an CP is used.
o NMS Driven MPLS-TP (ND MPLS-TP), LSPs, PWs and segments is set up
and configured from an NMS
o Control Plane driven MPLS (CD MPLS-TP), LSPs, PWs and segments is
set up and configured from the control plane.
There are two variants of CD MPLS-TP depending on which routing
protocol that is used; for CD MPLS-TP there is a decision to use
the GMPLS version of RSVP-TE.
* based on RSVP-TE and OSPF-TE
* based on RSVP-TE and ISIS-TE
The fourth variant is MPLS-TP P2MP configured from an NMS
The fifth variant is when the MPLS-TP P2MP is configured from a
control plane using the MPLS signaling and routing protocols.
1.3.6. Additional Terms and Acronyms
This section lists terms and acronyms used in this document.
1.3.6.1. New terms
Control Plane Driven -
LSPs are set up and configured from the control plane. This is true
for almost all MPLS, but the Control Plane Driven terminology
originates from the MPLS-TP project.
Andersson & Martinotti Expires July 28, 2012 [Page 7]
Internet-Draft Unified MPLS Framework January 2012
NMS Driven -
LSPs are set up and configured from an NMS This is the mode Transport
Networks has been operated in traditionally.
1.3.6.2. Acronyms
CD MPLS-TP - Control Plane Driven MPLS-TP
CLI - Command Line Interface
EM - Element Manager
LCT - (correct expansion??)
MPLS-TD - Topology Driven MPLS
MPLS-TE - Traffic Engineered MPLS
MPLS-TP - MPLS for Transport Networks (MPLS Transport Profile)
ND MPLS-TP - NMS Driven MPLS-TP
NE - Network Element
NMS - Network Management System
TE P2MP - Traffic Engineered P2MP
1.3.7. MPLS Terminology structure
In the abbreviated table below a way of thinking about the
relationship between the MPLS RFCs, MPLS protocols, MPLS packages and
MPLS Aggregate Packages is outlined.
We take the approach that RFCs can be grouped into protocols, and
that protocols may form MPLS packages, which in turn can be grouped
into Aggregate Packages.
In talking about "MPLS RFCs" and "MPLS protocols" we do so in a wide
sense, i.e. RFCs and protocols that might be used in MPLS networks.
Most of those are developed by working groups that we listed as "MPLS
working groups" in RFC 4929 [RFC4929], but there are also other
protocols that are used and necessary in some MPLS networks, e.g. the
IGPs that were developed in other working groups.
We have added NMS Configuration and MPLS Data Plane, even though they
they are not "protocols" of the same flavor as the other protocols
Andersson & Martinotti Expires July 28, 2012 [Page 8]
Internet-Draft Unified MPLS Framework January 2012
MPLS Terminology Structure
- a strawman ontology
---------------------------------------------------------------------
MPLS RFCs (examples)
RFC5036 RFC3478 RFC3479 RFC3209 RFC3477 RFC6428
RFC3031
RFC3032 RFC3033 RFC3034 RFC3035 RFC3038 RFC3107
RFC3209 RFC3270 RFC3473 RFC3477 RFC3478 RFC3479
RFC3811 RFC3812 RFC3813 RFC3814 RFC3815 RFC4023
RFC4090 RFC4182 RFC4201 RFC4206 RFC4220 RFC4368
RFC4379 RFC5420 RFC4561 RFC4781 RFC4817 RFC4875
RFC4950 RFC5283 RFC5330 RFC5331 RFC5332 RFC5462
RFC%%61 RFC5586 RFC5710 RRFC5711 RFC5712 RFC5718
RFC5918 RFC5919 RFC5960 RFC6178 RFC6370 RFC6372
RFC6374 RFC6375 RFC6378 RFC6388 RFC6424 (mLDP)
RFC5316 RFC5392 etc
RFC2328 RFC2370
RFC1195 RFC3784 RFC4205
RFC5880 RFC5884
(depending on how one counts the number of RFCs may vary)
---------------------------------------------------------------------
MPLS
Protocols
+----------+----------+----------+----------+----------+
| LDP | OSPF | ISIS | RSVP-TE | LSP-PING |
+----------+----------+----------+----------+----------+
| RFC5036 | RFC2328 | RFC1195 | RFC5712 | RFC6424 |
+----------+----------+----------+----------+----------+
| RFC6388 | | | RFC5711 | RFC4379 |
+----------+----------+----------+----------+----------+
| RFC5919 | | | RFC5710 | |
+----------+----------+----------+----------+----------+
| RFC5918 | | | RFC5330 | |
+----------+----------+----------+----------+----------+
| RFC5561 | | | RFC4875 | |
+----------+----------+----------+----------+----------+
| (mLDP) | | | RFC3209 | |
+----------+----------+----------+----------+----------+
| etc | | | etc | |
+----------+----------+----------+----------+----------+
+----------+----------+----------+----------+----------+
Andersson & Martinotti Expires July 28, 2012 [Page 9]
Internet-Draft Unified MPLS Framework January 2012
| MPLS-OAM | OSPF-TE | ISIS-TE | BFD | NMS Conf |
+----------+----------+----------+----------+----------+
| RFC6378 | RFC2370 | RFC3784 | RFC5880 | nil |
+----------+----------+----------+----------+----------+
| RFC6375 | RFC3471 | RFC5316 | RFC5884 | |
+----------+----------+----------+----------+----------+
| RFC6374 | RFC3473 | RFC4205 | | |
+----------+----------+----------+----------+----------+
| RFC6372 | RFC4203 | | | |
+----------+----------+----------+----------+----------+
| RFC6370 | | | | |
+----------+----------+----------+----------+----------+
| RFC5586 | | | | |
+----------+----------+----------+----------+----------+
| etc | | | | |
+----------+----------+----------+----------+----------+
+----------+----------+----------+----------+----------+
| MPLS-DP | MPLS-NM | BGP | | |
+----------+----------+----------+----------+----------+
| RFC6178 | RFC5718 | RFC3107 | | |
+----------+----------+----------+----------+----------+
| RFC5960 | RFC4368 | | | |
+----------+----------+----------+----------+----------+
| RFC5462 | RFC4220 | | | |
+----------+----------+----------+----------+----------+
| RFC4182 | RFC3815 | | | |
+----------+----------+----------+----------+----------+
| RFC4023 | RFC3814 | | | |
+----------+----------+----------+----------+----------+
| RFC3473 | RFC3813 | | | |
+----------+----------+----------+----------+----------+
| etc | etc | | | |
+----------+----------+----------+----------+----------+
---------------------------------------------------------------------
MPLS Packages
+-----------+-----------+-----------+-----------+-----------+
| MPLS-TD 1 | MPLS-TD 2 | MPLS-TD | MPLS-TD | GMPLS 1 |
| | | P2MP 1 | P2MP 2 | |
+===========+===========+===========+===========+===========+
| ISIS | OSPF | ISIS | OSPF | OSPF-TE |
+-----------+-----------+-----------+-----------+-----------+
| LDP | LDP | LDP | LDP | RSVP-TE |
+-----------+-----------+-----------+-----------+-----------+
Andersson & Martinotti Expires July 28, 2012 [Page 10]
Internet-Draft Unified MPLS Framework January 2012
| | | RFC6388 | RFC6388 | |
| | | (mLDP) | (mLDP) | |
+-----------+-----------+-----------+-----------+-----------+
+-----------+-----------+-----------+-----------+-----------+
| MPLS-TD | | | | |
| BGP | | | | |
+===========+===========+===========+===========+===========+
| BGP | | | | |
| RFC3107 | | | | |
+-----------+-----------+-----------+-----------+-----------+
+-----------+-----------+-----------+-----------+-----------+
| MPLS-TE 1 | MPLS-TE 2 | MPLS-TE | MPLS-TE | GMPLS 2 |
| | | P2MP 1 | P2MP 2 | |
+===========+===========+===========+===========+===========+
| ISIS-TE | OSPF-TE | ISIS-TE | OSPF-TE | ISIS-TE |
+-----------+-----------+-----------+-----------+-----------+
| RSVP-TE | RSVP-TE | RSVP-TE | RSVP-TE | RSVP-TE |
+-----------+-----------+-----------+-----------+-----------+
| | | RFC4875 | RFC4875 | |
+-----------+-----------+-----------+-----------+-----------+
+-----------+-----------+-----------+-----------+-----------+
| MPLS-TP 1 | MPLS-T2 2 | MPLS-TP 3 | MPLS-TP 4 | MPLS-TP 5 |
|ND MPLS-TP |CD MPLS-TP | CD-MPLS-TP| P2MP TP | P2MP TP |
+===========+===========+===========+===========+===========+
| NMS conf | OSPF-TE | ISIS-TE | static | OSPF-TE |
+-----------+-----------+-----------+-----------+-----------+
| MPLSP OAM | RSVP-TE | RSVP-TE | RSVP-TE | RSVP-TE |
+-----------+-----------+-----------+-----------+-----------+
| | MPLS OAM | MPLS OAM | MPLS OAM | MPLS OAM |
+-----------+-----------+-----------+-----------+-----------+
---------------------------------------------------------------------
MPLS Aggregate Packages
+--------------+--------------+--------------+
| MPLS-TD | MPLS-TE | MPLS-TP |
| | | |
+==============+==============+==============+
| MPLS-TD 1 | MPLS-TE 1 | MPLS-TP 1 |
Andersson & Martinotti Expires July 28, 2012 [Page 11]
Internet-Draft Unified MPLS Framework January 2012
| | | ND MPLS-TP |
+--------------+--------------+--------------+
| MPLS-TD 2 | MPLS-TE 2 | MPLS-TP 2 |
| | | CD MPLS-TP |
+--------------+--------------+--------------+
| MPLS-TD | MPLS-TE | MPLS-TP 3 |
| P2MP 1 | P2MP 1 | CD MPLS-TP |
+--------------+--------------+--------------+
| MPLS-TD | MPLS-TE | MPLS-TP 4 |
| P2MP 2 | P2MP 2 | P2MP TP |
+--------------+--------------+--------------+
| | GMPLS 1 | |
| | | |
+--------------+--------------+--------------+
| | GMPLS 2 | |
| | | |
+--------------+--------------+--------------+
---------------------------------------------------------------------
MPLS Technology
---------------------------------------------------------------------
Andersson & Martinotti Expires July 28, 2012 [Page 12]
Internet-Draft Unified MPLS Framework January 2012
2. Unified MPLS Requirements
This section list the high level requirements for Unified MPLS.
2.1. Full Interoperability and Interworking
One important aspect of Unified MPLS is to promote interoperability
and interworking between different flavors of MPLS. Unified MPLS
addresses the problem of cross-MPLS interoperation and interworking.
Requirement: Unified MPLS SHALL guarantee full interoperability
between all MPLS packages, i.e. SHALL e.g. be possible to start an
LSP in an MPLS-TP network, cross MPLS-TE network and terminate it in
a MPLS-TD network.
2.2. Common Data Plane
Requirement: The actions taken on a MPLS encapsulated packet relative
to the label on top of the label stack, SHALL be the same regardless
if the LSP has been set up using any of the MPLS routing and
signaling protocols or if it has been established manually or from an
NMS.
2.3. Common OAM
OAM is defined as part of the data plane. One goal with Unified MPLS
is that it shall be possible to use MPLS-TP OAM for all MPLS
packages.
Requirement: Given that MPLS-TP OAM is used there SHALL NOT, from the
point of view of an MPLS encapsulated packet traversing the data
plane of a MPLS Network, be any differences depending on whether the
LSP has been set up using any of the MPLS routing and signaling
protocols or if it has been established manually or from an NMS.
2.4. Data Plane Agnostic
Requirement: The relationship between LSPs and the payload
transported on those LSPs, i.e. PWs, LSPs and IP, SHALL be the same
regardless if the payload is transported by one or the other of the
MPLS packages.
2.5. Interworking
Requirement: There SHALL be no limitations in the possibilities to
hand over payload from one LSP to another regardless of how the LSPs
has been established, i.e. it SHALL be possible to carry a PW on a
MPLS-TP or MPLS-TD segment and then hand it over to a MPLS-TE LSP and
Andersson & Martinotti Expires July 28, 2012 [Page 13]
Internet-Draft Unified MPLS Framework January 2012
vice versa.
Andersson & Martinotti Expires July 28, 2012 [Page 14]
Internet-Draft Unified MPLS Framework January 2012
3. Unified MPLS Overview
This section should contain a high-level overview of Unified MPLS.
Here we discuss interfacing different mpls types!
QUESTION: Do we have to consider also co-existence of different
packages (e.g. CD-MPLS-TP and MPLS-TE)? Do we want to consider a
network being physically partitioned or logically too?
QUESTION: Do we want to describe the possibility of reusing tools/
protocols defined into one package into other ones?
3.1. Unified MPLS Control Plane
Unified MPLS comprises a set of protocols for implementing a Control
Plane for Network Layer, for Routing and LSP label distribution. We
consider the following routing protocols: OSPF and ISIS and their
versions with Traffic Engineering extensions. We also consider the
following LSP label distribution protocols: LDP and RSVP-TE (and its
extensions for MPLS-TP). Each package having a control plane uses a
combination of them.
We also consider the possibility where PW level is setup and
maintained via tLDP.
One aim of Unified MPLS is to consider the Control Plane implications
of putting two network domains in relationship, where one or both of
them implements a control plane; not all the combinations may
interwork in principle. Further considerations are done in
Section 4.4.
3.2. Unified MPLS Data Plane
Unified MPLS comprises a standard MPLS data plane [RFC3031]. The
following information is relevant to Unified MPLS.
The forwarding functions comprise the mechanisms required for
forwarding the encapsulated native service traffic over an MPLS
network, for example, LSP and PW labels.
MPLS label switching operations and Time-to-Live (TTL) processing
procedures are used, as defined in [RFC3031], [RFC3032], [RFC3443]
and [RFC5921].
SS-PW and MS-PW forwarding operations are used, as defined in
[RFC3985] and [RFC5659].
Per-platform label space is used for PWs. Either per-platform, per-
Andersson & Martinotti Expires July 28, 2012 [Page 15]
Internet-Draft Unified MPLS Framework January 2012
interface, or other context-specific label space [RFC5331] may be
used for LSPs.
MPLS forwarding is based on the label that identifies the path (LSP
or PW). The label value 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. TTL expiry, which is
a fundamental architectural construct of MPLS to be taken into
account when designing protocol extensions (such as those for OAM)
that require packets to be sent to an intermediate LSR.
Further processing to determine the context of a packet occurs when a
swap operation is interrupted in this manner, or a pop operation
exposes a specific reserved label at the top of the stack (including
the GAL). Otherwise, the packet is forwarded according to the
procedures in [RFC3032].
MPLS Differentiated Services (Diffserv) architecture [RFC3270] is the
suggested mode of supporting Quality of Services in Unified MPLS.
Both E-LSP and L-LSP MPLS Diffserv modes are supported.
Multicast MPLS is left for further study within Unified MPLS.
3.3. Unified MPLS Management
Here we want to describe the possible methods for Management of
Unified MPLS. Commonly used methods, such as CLI, may be used in
conjunction with LCT, EM, NMS, as described in [RFC5950]. Most
important functions related to Management are: provisioning of
network layer and service layer, fault and performance monitoring,
inventory.
In several profiles of MPLS, provisioning of network layer and
service layer is done by means of Control Plane. Where Management
plane only is used for provisioning (e.g. in ND-MPLS-TP), routing,
Path Computation Element, label distribution, configuration of the
parameters for network and service layer are done via network
management tools.
Where several subnetworks are deployed, it may happen that only a
subset of them is operated via Management, while another is operated
via Control Plane. The dependencies of the two has to be analysed.
Andersson & Martinotti Expires July 28, 2012 [Page 16]
Internet-Draft Unified MPLS Framework January 2012
3.4. Unified MPLS OAM
OAM is used to perform functions of operation, administration and
maintenance (a comprehensive description of OAM functions is
described in [RFC6291]). These functions are applicable both to LSP
and PW. Among all the functions provided by OAM, fault management
and performance monitoring are used to have a common method to verify
the behavior of a network domain and a single mean to monitor the
different kinds of service being provided.
OAM for MPLS has been defined in [LIST-OF-RFC-OF-OAM-FOR-LSP],
especially because of the requirements of MPLS-TP. OAM for PW has
been defined in [LIST-OF-RFC-OF-OAM-FOR-PW].
One critical objective of Unified MPLS is to describe how these tools
can be used in a multi-domain MPLS network, where different packages
can be deployed.
Andersson & Martinotti Expires July 28, 2012 [Page 17]
Internet-Draft Unified MPLS Framework January 2012
4. Interfaces and Interworking
Where two or more subnetworks (or profiles instances) are deployed
within an operator network, it is important to consider the interface
between each pair of them. Peering relationship is where the two
subnetworks are at the same level with respect to the end-to-end
service being provided. Peering relationship may happen at LSP, PW
or client service level. Overlay relationship is where one
subnetwork is client of the other one, so that the server subnetwork
provides connectivity to part of the client one. In this section we
discuss the most important interfaces and subnetwork interworking.
4.1. Interfaces
Several packages are considered within MPLS Technology. Anyhow there
is not yet a guideline on how to use a combination of different
packages in a single operator network. With Unified MPLS we want to
describe the interfaces between the different packages. The number
of the possible interfaces is quite high, so a brute force approach
for their description is not beneficial to the reader. An objective
of Unified MPLS is to start the analysis with the most common
interworking scenarios.
The interface between two domains may be a node or a link. The two
cases may lead to different requirements and behaviors at the
interface. It may happen that one or several interfaces (of the same
kind) happen between two domains.
4.2. Network Layer Interworking
This document uses the term Network Layer in the same sense as it is
used in [RFC3031] and [RFC3032].
Two peering network domains (each one implementing one instance of
any MPLS package) interwork at Network Layer when they are configured
to interconnect at LSP or PW level. LSP stitching and MS-PW are
used, depending on the level chosen. LSP stitching may be used for
any client signal encapsulated into the end-to-end LSP (MPLS, PW,
IP), while MS-PW can only be used for PW encapsulated signals.
4.3. Service Layer Interworking
Service interface (UNI and NNI) reference models are described in
[RFC5921] and further analyzed in [RFC6125].
Two peering network domains (each one implementing one instance of
any MPLS package) interwork at Service Layer when they are configured
to interconnect at client service level. In case of border link
Andersson & Martinotti Expires July 28, 2012 [Page 18]
Internet-Draft Unified MPLS Framework January 2012
interconnecting the two domains, it can be named UNI in [RFC6125]
terminology.
In case of border node interconnecting the two domains, Termination
mode applies.
4.4. Network Overlay
When two network domains are in Overlay relationship, in principle
there isn't any interworking between them. Anyhow there are few
aspects to be taken into account, at least from CP and Fault
Management point of view.
CP aspects has to be considered when the client network domain is CD
(it implements a CP). If the server network domain is CD, there is
the possibility to interact between the two CPs. if the server
network is ND, then the resources for the client domain must be pre-
allocated.
In case OAM tool set is used in both client and server network
domain, there is the possibility to propagate fault indication,
happened within the server domain, into the client domain.
One Unified MPLS aim is also to specific constraints given by the
used packages (E.g. if a domain using MPLS-TE is client of a domain
using MPLS-TD, bandwidth requirements of the client layer may not be
guaranteed.
Andersson & Martinotti Expires July 28, 2012 [Page 19]
Internet-Draft Unified MPLS Framework January 2012
5. MPLS Resiliency
This section will dicuss different aspects of MPLS resiliency, like
protection, suvivability and recovery.
5.1. MPLS Recovery
Note: Text needed!
5.2. MPLS Protection
Note: Text needed!
5.3. MPLS Survivability
Note: Text needed!
Andersson & Martinotti Expires July 28, 2012 [Page 20]
Internet-Draft Unified MPLS Framework January 2012
6. Other Unified MPLS Considerations
It is quite possible that Unified MPLS should also address a number
of other aspects of MPLS.
Andersson & Martinotti Expires July 28, 2012 [Page 21]
Internet-Draft Unified MPLS Framework January 2012
7. Security Considerations
Security considerations to be added.
Andersson & Martinotti Expires July 28, 2012 [Page 22]
Internet-Draft Unified MPLS Framework January 2012
8. IANA considerations
There are no IANA considerations for this document (at least
currently) an IANA section will be added as necessary.
Andersson & Martinotti Expires July 28, 2012 [Page 23]
Internet-Draft Unified MPLS Framework January 2012
9. Acknowledgments
We have recieved valuable feeback from several people working with
adapting and utilizing MPLS in their networks.
Andersson & Martinotti Expires July 28, 2012 [Page 24]
Internet-Draft Unified MPLS Framework January 2012
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
November 1998.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for
Multiprotocol Label Switching Architecture (MPLS)
Operation and Maintenance (OAM) Functions", RFC 3429,
November 2002.
[RFC4929] Andersson, L. and A. Farrel, "Change Process for
Multiprotocol Label Switching (MPLS) and Generalized MPLS
(GMPLS) Protocols and Procedures", BCP 129, RFC 4929,
June 2007.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
10.2. Informative references
[I-D.bryant-mpls-tp-jwt-report]
Bryant, S. and L. Andersson, "JWT Report on MPLS
Architectural Considerations for a Transport Profile",
draft-bryant-mpls-tp-jwt-report-00 (work in progress),
July 2008.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks",
RFC 5921, July 2010.
Andersson & Martinotti Expires July 28, 2012 [Page 25]
Internet-Draft Unified MPLS Framework January 2012
Authors' Addresses
Loa Andersson
Ericsson
Email: loa@pi.nu
Riccardo Martinotti
Ericsson
Email: riccardo.martinotti@ericsson.com
Andersson & Martinotti Expires July 28, 2012 [Page 26]
