Internet DRAFT - draft-allan-mpls-unified-ic-req-frmwk
draft-allan-mpls-unified-ic-req-frmwk
MPLS Working Group Dave Allan, Ed.
Internet Draft Ericsson
Intended status: Standards Track
Expires: September 2012 March 2012
Requirements and Framework for Unified MPLS Sub-Network
Interconnection
draft-allan-mpls-unified-ic-req-frmwk-01
Abstract
The definition of a transport profile for MPLS means that MPLS
network architectures will emerge that combines both managed and
control plane driven MPLS sub-networks and requires interconnection
of same to achieve a unified MPLS architecture.
This document generalizes the problem of sub-network interconnect,
discusses issues in general and suggests ways forward.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [1].
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance
with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
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".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
Allan et al., Expires September 2012 [Page 1]
Internet-Draft draft-allan-mpls-unified-ic-req-frmwk-01 March 2012
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire in September 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.
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................4
2.1. Terminology..................................................4
2.2. Acronyms.....................................................4
3. Sub-Network Interconnect Scenarios.............................4
4. Sub-Network Interconnect Mechanisms............................5
4.1. Border Node..................................................5
4.2. Border Link..................................................5
5. Sub-network types..............................................5
5.1. Infrastructure sub-network types.............................5
5.2. Service Sub-network types....................................6
6. Issues & Requirements..........................................6
6.1. Alignment of OAM functionality...............................7
6.2. OAM identifier mismatches....................................7
6.3. OAM encapsulation............................................7
6.4. Protection Mechanisms........................................8
6.5. Label space management.......................................8
6.6. Path maintenance and re-sizing...............................8
6.7. Sub-network migration........................................9
6.8. (Non)Interworking of DP and CP notifications.................9
7. Operational Decoupling.........................................9
8. Acknowledgments...............................................10
9. IANA Considerations...........................................10
10. Security Considerations......................................10
11. References...................................................10
11.1. Informative References.....................................10
Allan et al., Expires July, 2012 [Page 2]
Internet-Draft draft-allan-mpls-unified-ic-req-frmwk-01 March 2012
1. Introduction
Networks that provide an end-to-end service infrastructure are
typically deployed as multiple domains or sub-networks in order to
scale. These different domains may be operated by different
technologies using different control plane technology (e.g.
management driven control plane (centralized) or distributed control
plane).
Within the MPLS control plane there exist a number of functional
behaviors that are typically associated with a single control
protocol and function autonomously from the other control protocols.
That is to say when a labeled layer and associated control protocol
is overlaid on another, there is frequently no operational coupling
between them. When two control protocols are operated side by side
the same is true (e.g. ships in the night). An example of the former
would be pseudo wires over a PSN. An example of the latter would be
L2 and L3 virtual private networks (VPNs) sharing a common packet
switched network (PSN).
The introduction of transport functions to MPLS and the intent to
deploy, merge or otherwise combine networks that will concatenate
sub-networks that have different operational characteristics and/or
control planes (including management) introduces the requirement to
integrate operations across multiple sub-networks. This frequently is
manifested in requirements on nodes at sub-network boundaries and/or
alignment of identifiers in order to construct a unified end-to-end
MPLS based service plane.
By having a unified MPLS based service plane, a network operator is
able to provide services across different MPLS domains instrumented
with common management and control functionality in order to provide
scalable service offerings on a common MPLS technology base.
This document is a framework that postulates models and functional
requirements for sub-network interconnect to achieve a unified end to
end MPLS based service plane or "Unified MPLS".
Allan et al., Expires July, 2012 [Page 3]
Internet-Draft draft-allan-mpls-unified-ic-req-frmwk-01 March 2012
2. Conventions used in this document
2.1. Terminology
Binding: Is the mechanism for association and interconnection of
label switched path (LSP) or pseudo wire (PW) segments that exist in
different sub-networks.
Section: As per RFC 5960[17].
Segment: A part of a PW or LSP that has one or more contiguous
sections in a common sub-network. This usage is as per RFC 6372[18].
Sub-network: A portion of a larger MPLS network that is operated by a
single system and whose boundaries are set by the scope of the
system. The system may be a control plane or management system.
Similarly it could be a sub-layer stacked on another sub-network.
2.2. Acronyms
LIB - label information base
LSP - label switched path
MEG - Maintenance Entity Group
MEP - Maintenance Entity Group End Point
MIP - Maintenance Entity Group Intermediate Point
PSN - packet switched network
PW - pseudo wire
SPME - Sub-path Maintenance Entity
VPWS - Virtual Private Wire Service
VPMS - Virtual Private Multicast Service
3. Sub-Network Interconnect Scenarios
The combination of MPLS label swapping and label stacking makes it
possible to consider a number of atomic interconnect scenarios,
briefly summarized here:
Peer Model - is the scenario when an LSP or PW has segments in
different sub-networks.
Allan et al., Expires July, 2012 [Page 4]
Internet-Draft draft-allan-mpls-unified-ic-req-frmwk-01 March 2012
Segmentation Model - is the scenario when a client LSP or PW with
common establishment and maintenance procedures has sections in
separate sub-networks. This model can recurse arbitrarily.
Overlay Model - is the simplest case of the segmentation model in
which a section of an LSP or PW is a distinct sub-network. This is
currently the common deployment scenario for MPLS, and normally has
minimal dependencies. In the specific case of MPLS & GMPLS, the
requirements are examined in RFC 5146[21].
Termination Model - is the scenario where a non-MPLS or PW transfer
function separates the sub-networks. The termination model logically
isolates the sub-networks and is included simply for completeness.
4. Sub-Network Interconnect Mechanisms
There are two interconnect mechanisms considered. The first (Border
node) postulates a node that spans two sub-networks and both likely
operated by a single provider. The second (Border link) postulates a
link connecting sub-networks of two distinct organizations within a
provider or two distinct providers.
4.1. Border Node
A border node is one that implements, interconnects and interworks
LSPs or PWs with segments or sections in different sub-networks. The
interworking function at the border node will either terminate, swap
or encapsulate labels.
4.2. Border Link
A border link is the case whereby two border nodes are connected back
to back in an MPLS sub-network that consists of a single link. This
can be a physical link or a logical link (e.g. an MPLS section).
5. Sub-network types
In the current MPLS architecture the following sub-network types
exist:
5.1. Infrastructure sub-network types
The infrastructure sub-network types are:
MPLS-TD: Topology driven MPLS. LSP setup is via the LDP protocol [6]
with path routing determined by the IGP. ECMP, merging and PHP are
are included in the set of possible dataplane behaviors. LSPs are
unidirectional only. P2mp and mp2mp LSPs are supported by mLDP [7].
Allan et al., Expires July, 2012 [Page 5]
Internet-Draft draft-allan-mpls-unified-ic-req-frmwk-01 March 2012
MPLS-TE: LSP setup is via the RSVP-TE protocol[8] with path routing
determined by a TE enabled IGP (e.g. OSPF-TE) according to bandwidth
and QoS constraints. PHP is included in the set of dataplane
behaviors. LSPs are unidirectional only. Bandwidth allocations, class
of service or priority(PHB) are typically part of traffic handling.
Managed MPLS-TP: LSP setup is via management action. LSPs can be uni-
directional, bi-directional or associated bi-directional. LSPs are
purely connection oriented p2p or p2mp (where p2mp is unidirectional
only).
Signalled MPLS-TP: LSP setup is via RSVP-TE GMPLS[9]. LSPs can be
uni-directional, bi-directional or associated bi-directional. LSPs
are purely connection oriented p2p or p2mp (where p2mp is
unidirectional only).
And it is possible to consider
GMPLS for non-MPLS dataplanes:
5.2. Service Sub-network types
L3VPN: VPN setup is via the BGP protocol as per RFC 4364[10]. Note
that this can be an IP-VPN (via IGP peering with the VRF) or an MPLS-
VPN (via a combination of IGP and MPLS CP peering with the VRF).
L2VPN: VPN setup is via the PW Control Protocol per RFC 4447 (LDP in
targeted mode) or BGP protocols. A broadcast domain is emulated which
will have the effect of limiting sub-network interconnect to a single
point to avoid loops.
VPWS: VPWS setup is via the PW Control Protocol per RFC 4447 (LDP in
targeted mode).
VPMS: VPMS setup is currently an L2VPN work item .
[20].
6. Issues & Requirements
In theory, any ingress label can be mapped to one or more egress
labels or label stack permutations via the ILM to NHLFE mapping
defined in RFC 3031[2]. Further one carrier"s infrastructure layer
may be a client of another carrier"s infrastructure. More
considerations need to come into play in order to produce a tractable
set of sub-network interworking scenarios. The following is a partial
list of some of the issues to be considered and/or addressed:
Allan et al., Expires July, 2012 [Page 6]
Internet-Draft draft-allan-mpls-unified-ic-req-frmwk-01 March 2012
6.1. Alignment of OAM functionality
Not all OAM encapsulations guarantee fate sharing with the LSP of
interest across all of the sub-network types in MPLS. This not only
means that failures may not be detected or detected in a timely
manner, it also means that "false positives" are a possibility as
failures may occur on the path taken by the OAM PDUs.
Any OAM encapsulation using a reserved label, e.g. the GAL[12], or
Router Alert as used by VCCV type 2[13], or without a PW control word
will not have predictable control over fate sharing with normal
payload for any LSP or PW that has a section that transits a MPLS-TD
sub network that implements ECMP[11]. Specifying that ECMP
implementations exclude reserved labels from consideration would
permit ECMP and LAG approaches that limit the sources of entropy to
the label stack (e.g. FAT PWs [ref] or the entropy label [ref]) to be
employed and be correctly and reliably instrumented by OAM that used
a reserved label.
A separate issue is interconnecting sub networks where the LSPs have
a different cardinality of end points (e.g. concatenating mp2p to
p2p), implying a different number of maintenance entities than would
be suggested by an implementation dimensioned to a single sub
network"s characteristics.
6.2. OAM identifier mismatches
MEG, MEP, MIP and nodal addressing will not pose identifier mismatch
problems. Where such problems will arise is in the use of RFC 4379
LSP Ping [3]. This is because LSP-PING uses identifiers associated
with a specific sub-network type in the FEC stack as part of the
processing to detect inconsistencies between the control plane and
the data plane.
[Issue: The on demand CV draft provides for the Static LSP and Static
PW TLVs for the FEC stack which allows intermediate nodes to validate
the FEC stack against the MEG ID for the local MIP. The applicability
for this should be generalized such that it can be used end to end
across domains. This will also raise the problem of disseminating MEG
information to non-transport sub networks as not all defined MPLS
sub-network types use the current fields in the IP based LSP MEG ID]
6.3. OAM encapsulation
The MPLS architecture permits multiple OAM encapsulations that may or
may nor have an IP header. Any interconnect mechanism needs to be
able to align not only capability but encapsulations end to end. This
Allan et al., Expires July, 2012 [Page 7]
Internet-Draft draft-allan-mpls-unified-ic-req-frmwk-01 March 2012
document assumes that translation of encapsulations by MIPs will not
be specified or implemented.
6.4. Protection Mechanisms
An MPLS LSP or PW sub-network may be made resilient by any number of
mechanisms. There are also three scenarios of note, end to end
protection, end to end restoration and sub-network protection.
End to end protection offers minimal complications in sub-network
interconnect as the interworking functions is common to that of the
unprotected case, that is to say transit nodes do not participate in
protection switching.
Sub-network protection is universally offered by the use of
mechanisms that operate within the level such as detours [19] and may
require label merging at the border node. Mechanisms that operate at
nested MPLS label levels (e.g. SPMEs or FRR facility protection) have
no impact on sub-network interconnect.
End to end restoration is a bit more complicated as it involves
coordinating dynamic action between sub-networks.
It also becomes possible to consider sub-network restoration with
many of the same considerations as path maintenance and re-sizing.
6.5. Label space management
The MPLS architecture has always been based around local
administration of a node"s label space. As such mechanisms to
partition the label space between multiple administrative entities is
not currently supported and would be difficult to retrofit.
A consequence of this is that a border node is potentially required
to provide labels from a common pool to both a control and management
plane, e.g. a management system be required to obtain label values
from the node prior to populating the LIB vs. being delegated a pool.
This suggests that such a mechanism be carried forward for all
managed nodes such that only a single mechanism need be implemented.
However this is an implementation decision.
6.6. Path maintenance and re-sizing
It must be possible to make operational modifications to a path
segment in a hitless fashion. The normal procedure for MPLS-TE is
known as "make before break". This gives rise to two scenarios, the
first is end to end "make before break", and the other is make before
break confined to a sub-network with the border node as a pinned
Allan et al., Expires July, 2012 [Page 8]
Internet-Draft draft-allan-mpls-unified-ic-req-frmwk-01 March 2012
waypoint. This means the design of the inter-sub-network binding
information permit make before break modification of one segment of
the LSP.
6.7. Sub-network migration
The practical considerations are documented in RFC 5950[4] and by
reference RFC 5493[5].
6.8. (Non)Interworking of DP and CP notifications
Within the MPLS architecture there are techniques for propagating the
status of adjacent sections of either a native service or PW section
in both the data plane and the control plane. One example
(documenting both) is RFC 6310[14].
When concatenating sub networks the interworking of dataplane fault
notifications [15] or protection switching coordination [16] and
control plane indications will not be possible. The reason is that
data plane indications flow end to end on a labeled path therefore
will not be visible to border nodes, a requirement to enable
interworking of dataplane notifications with the control plane in any
useful form.
When connecting a sub network restricted to data plane only
notifications to a sub network that will support either dataplane or
control plane notifications, the border node will be required to
negotiate exclusive use of dataplane notifications in any control
plane signaling during the path setup. This will have implications in
both the interconnect data model, and potential enhancements to
signaling.
7. Operational Decoupling
The objective of any sub-network interconnect solution is to decouple
the operation of the interconnected systems in order to minimize any
dependencies.
The sub-network interconnect must accommodate interconnecting LSPs
and PWs with different establishment and persistency characteristics.
This is determined by whether the LSP, PW or segment is provisioned
or signaled, where from a persistency point of view, a provisioned
entry is permanent and exists until removed by management action,
while a signaled entity fate shares with a control plane adjacency
and may come and go during the life time of the inter sub-network
binding.
Allan et al., Expires July, 2012 [Page 9]
Internet-Draft draft-allan-mpls-unified-ic-req-frmwk-01 March 2012
The state present at a border node to bind the LSP or PW spanning the
sub networks together should exist independently of the
characteristics of the LSPs or associated control or management
planes.
This also requires a level of indirection such that the management
action is decoupled from the mechanics of label assignment in each
sub-network and may work with sub-network resiliency mechanisms.
So the state "connect whatever label from sub-network A associated
with FOO to whatever label from sub-network B is associated with BAR"
should be persistent.
8. Acknowledgments
Loa Andersson, Mach Chen, Eric Gray, David Sinicrope and Greg Mirsky
contributed to the development of this document.
9. IANA Considerations
This document does not require IANA action.
10. Security Considerations
Sub-network interconnect in a single provider scenario does not
introduce any new security exposures to the MPLS architecture that do
not already exist.
Sub-network interconnect in a multi-provider scenario (e.g. border
link) introduces a number of potential exposures, and requires a
strong trust model for the co-ordination of the set up if interdomain
LSPs. This is particularly true for the peer model. This is somewhat
mitigated when operational decoupling techniques are employed as
discussed in section 7, as the scope of what a provider can ask of a
peer network is explicitly scoped.
11. References
11.1. Informative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosen et.al. Multiprotocol Label Switching Architecture, IETF
RFC 3031, January 2001
[3] Kompella et.al. Detecting Multi-Protocol Label Switched (MPLS)
Data Plane Failures, IETF RFC 4379, February 2006
Allan et al., Expires July, 2012 [Page 10]
Internet-Draft draft-allan-mpls-unified-ic-req-frmwk-01 March 2012
[4] Mansfield et. al. Network Management Framework for MPLS-based
Transport Networks, IETF RFC 5950, September 2010
[5] Caviglia, D., Bramanti, D., Li, D., and D. McDysan,
"Requirements for the Conversion between Permanent Connections and
Switched Connections in a Generalized Multiprotocol Label
Switching (GMPLS) Network", RFC 5493, April 2009.
[6] Andersson et.al. "LDP Specification", IETF RFC 5036, October
2007
[7] Minei, I. et.al. "Label Distribution Protocol Extensions for
Point-to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", IETF RFC 6388
[8] Awduche et.al. "RSVP-TE: Extensions to RSVP for LSP Tunnels",
IETF RFC 3209, December 2001
[9] Berger et.al. "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", IETF RFC 3471, January
2003
[10] Rosen et.al. "BGP/MPLS IP Virtual Private Networks (VPNs)",
IETF RFC 4364, February 2006
[11] Swallow et.al. "Avoiding Equal Cost Multipath Treatment in MPLS
Networks", IETF RFC 4928, June 2007
[12] Bocci et.al. "MPLS Generic Associated Channel", IETF RFC 5586,
June 2009
[13] Nadeau et.al "Pseudowire Virtual Circuit Connectivity
Verification (VCCV) A Control Channel for Pseudowires", IETF RFC
5085, December 2007
[14] Aissaoui et.al. "Pseudowire (PW) Operations, Administration,
and Maintenance (OAM) Message Mapping", IETF RFC 6310, July 2011
[15] Swallow et.al. "MPLS Fault Management OAM", IETF RFC 6427,
November 2011
[16] Bryant et.al. "MPLS-TP Linear Protection", IETF RFC 6378,
October 2011
[17] Frost et.al. "MPLS Transport Profile Data Plane Architecture",
IETF RFC 5960, August 2010
Allan et al., Expires July, 2012 [Page 11]
Internet-Draft draft-allan-mpls-unified-ic-req-frmwk-01 March 2012
[18] Sprecher et.al. "MPLS Transport Profile (MPLS-TP) Survivability
Framework", IETF RFC 6372, September 2011
[19] Pan et.al. "Fast Reroute Extensions to RSVP-TE for LSP
Tunnels", IETF RFC 4090, May 2005
[20] Kamite et.al., "Framework and Requirements for Virtual Private
Multicast Service (VPMS)", IETF work in progress, draft-ietf-
l2vpn-vpms-frmwk-requirements-04.txt, July 2011
[21] Kumaki et.al., Interworking Requirements to Support Operation
of MPLS-TE over GMPLS Networks, IETF RFC 5146, March 2008
Authors' Addresses
Dave Allan
Ericsson
Email: david.i.allan@ericsson.com
Allan et al., Expires July, 2012 [Page 12]
