[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-allan-mpls-unified-ic-req-frmwk

MPLS Working Group                                       Dave Allan, Ed.
Internet Draft                                                 Ericsson
Intended status: Standards Track
Expires: April 2012                                        October 2011


          Requirements and Framework for Unified MPLS Sub-Network
                              Interconnection


                 draft-allan-unified-mpls-ic-req-frmwk-00


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 April 2012                   [Page 1]


Internet-Draft  draft-allan-unified-mpls-ic-req-frmwk-00    October 2011


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire in January 2012.

Copyright Notice

   Copyright (c) 2011 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 connectivity models..Error! Bookmark not defined.
   6.2. Alignment of OAM functionality...............................6
   6.3. OAM identifier mismatches....................................7
   6.4. Protection Mechanisms........................................7
   6.5. Label space management.......................................8
   6.6. Path maintenance and re-sizing...............................8
   6.7. Sub-network migration........................................8
   6.8. (Non)Interworking of DP and CP notifications.................8
   7. Operational Decoupling.........................................9
   8. Acknowledgments................................................9
   9. IANA Considerations............................................9
   10. Security Considerations.......................................9
   11. References...................................................10
   11.1. Informative References.....................................10

Allan et al.,            Expires April, 2012                   [Page 2]


Internet-Draft  draft-allan-unified-mpls-ic-req-frmwk-00    October 2011




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 April, 2012                   [Page 3]


Internet-Draft  draft-allan-unified-mpls-ic-req-frmwk-00    October 2011


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

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.

   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.

Allan et al.,            Expires April, 2012                   [Page 4]


Internet-Draft  draft-allan-unified-mpls-ic-req-frmwk-00    October 2011


   Overlay Model - is the simplest case of the segmentation model in
   which a section of an LSP or PW is a distinct sub-network.

   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 a sub-network that consists of a single link.

5. Sub-network types

   In the current MPLS architecture the following sub-network types
   exist:

5.1. Infrastructure sub-network types

   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. P2mp LSPs
   are supported by mLDP [7].

   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. Bandwidth allocation, class of service or priotity(PHB)
   are typically part of traffic handling.

   Managed MPLS-TP: LSP setup is via management action. LSPs are purely
   connection oriented p2p or p2mp.


Allan et al.,            Expires April, 2012                   [Page 5]


Internet-Draft  draft-allan-unified-mpls-ic-req-frmwk-00    October 2011


   Signalled MPLS-TP: LSP setup is via RSVP-TE GMPLS[9]. LSPs are purely
   connection oriented p2p or p2mp.

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).

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:

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
   subnetwork that implements ECMP[11].

   A separate issue is interconnecting subnetworks 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 subnetwork"s
   characteristics.



Allan et al.,            Expires April, 2012                   [Page 6]


Internet-Draft  draft-allan-unified-mpls-ic-req-frmwk-00    October 2011


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 subnetworks 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.

6.4. Protection Mechanisms

   An MPLS LSP or PW sub-network may be made resilient by any number of
   mechanisms. There is 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.




Allan et al.,            Expires April, 2012                   [Page 7]


Internet-Draft  draft-allan-unified-mpls-ic-req-frmwk-00    October 2011


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
   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 subnetworks 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 subnetwork restricted to data plane only
   notifications to a subnetwork that will support either dataplane or

Allan et al.,            Expires April, 2012                   [Page 8]


Internet-Draft  draft-allan-unified-mpls-ic-req-frmwk-00    October 2011


   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.

   The state present at a border node to bind the LSP or PW spanning the
   subnetworks 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, 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

   For a future version of this document.



Allan et al.,            Expires April, 2012                   [Page 9]


Internet-Draft  draft-allan-unified-mpls-ic-req-frmwk-00    October 2011


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

[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 work in progress, draft-ietf-mpls-ldp-p2mp-15

[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



Allan et al.,            Expires April, 2012                  [Page 10]


Internet-Draft  draft-allan-unified-mpls-ic-req-frmwk-00    October 2011


[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 work in
      progress, draft-ietf-mpls-tp-fault-07, September 2011

[16]     Bryant et.al. MPLS-TP Linear Protection, IETF work in progress,
      draft-ietf-mpls-tp-linear-protection-09.txt, August 2011

[17]     Frost et.al. MPLS Transport Profile Data Plane Architecture,
      IETF RFC 5960, August 2010

[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


   Authors' Addresses

   Dave Allan
   Ericsson
   Email: david.i.allan@ericsson.com

























Allan et al.,            Expires April, 2012                  [Page 11]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/