MPLS-TP Applicability; Use Cases and Design
draft-ietf-mpls-tp-use-cases-and-design-05

INTERNET-DRAFT                                              L. Fang, Ed.
Intended Status: Informational                                     Cisco
Expires: July 12, 2013                                          N. Bitar
                                                                 Verizon
                                                                R. Zhang
                                                          Alcatel Lucent
                                                              M. Daikoku
                                                                    KDDI
                                                                  P. Pan
                                                                Infinera

                                                        January 12, 2013

             MPLS-TP Applicability; Use Cases and Design  
             draft-ietf-mpls-tp-use-cases-and-design-05.txt

Abstract

   This document provides applicability, use case studies and network
   design considerations for the Multiprotocol Label Switching Transport
   Profile (MPLS-TP). The use cases include Metro Ethernet access and
   aggregation transport, Mobile backhaul, and packet optical transport.

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/1id-abstracts.html

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

Copyright and License Notice
 

Fang et al.              Expires July 12, 2013                  [Page 1]
INTERNET DRAFT        MPLS-TP Use Cases and Design     December 16, 2012

   Copyright (c) 2013 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3. MPLS-TP Use Cases . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1. Metro Access and Aggregation  . . . . . . . . . . . . . . .  5
     3.2. Packet Optical Transport  . . . . . . . . . . . . . . . . .  6
     3.3. Mobile Backhaul . . . . . . . . . . . . . . . . . . . . . .  7
       3.3.1. 2G and 3G Mobile Backhaul . . . . . . . . . . . . . . .  7
       3.3.2. 4G/LTE Mobile Backhaul  . . . . . . . . . . . . . . . .  8
   4. Network Design Considerations . . . . . . . . . . . . . . . . .  8
     4.1. The role of MPLS-TP . . . . . . . . . . . . . . . . . . . .  8
     4.2. Provisioning mode . . . . . . . . . . . . . . . . . . . . .  9
     4.3. Standards compliance  . . . . . . . . . . . . . . . . . . .  9
     4.4. End-to-end MPLS OAM consistency . . . . . . . . . . . . . .  9
     4.5. PW Design considerations in MPLS-TP networks  . . . . . . . 10
     4.6. Proactive and on-demand MPLS-TP OAM tools . . . . . . . . . 10
     4.7. MPLS-TP and IP/MPLS Interworking considerations . . . . . . 11
   5. Security Considerations . . . . . . . . . . . . . . . . . . . . 11
   6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11
   7. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 12
   8. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1. Normative References  . . . . . . . . . . . . . . . . . . . 12
     8.2. Informative References  . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
   Contributors' Addresses  . . . . . . . . . . . . . . . . . . . . . 14

 

Fang et al.              Expires July 12, 2013                  [Page 2]
INTERNET DRAFT        MPLS-TP Use Cases and Design     December 16, 2012

1. Introduction

   This document provides applicability, use case studies and network
   design considerations for the Multiprotocol Label Switching Transport
   Profile (MPLS-TP). 

   In recent years, the urgency for moving from traditional transport
   technologies, such as SONET/SDH, TDM, and ATM, to new packet
   technologies has been rising. This is largely due to the fast growing
   demand for bandwidth, which has been fueled by the following factors:
   1) The growth of new services. This includes: the tremendous success
   of data services, such as IPTV and IP Video for content downloading,
   streaming, and sharing; the rapid growth of mobile services, as a
   consequence of the explosion of smart phone applications; the
   continued growth of business VPNs and residential broadband services.
   2) Network infrastructure evolution. As many legacy transport devices
   are approaching end of life, Service Providers transition to new
   packet technologies and evolve their transport network into the next
   generation packet transport. 

   As part of MPLS family, MPLS-TP complements existing IP/MPLS
   technologies; it closes the gaps in the traditional access and
   aggregation transport to enable end-to-end packet technology
   solutions in a cost efficient, reliable, and interoperable manner.
   After several years of industry debate on which packet technology to
   use, MPLS-TP has emerged as the next generation transport technology
   of choice for many Service Providers worldwide. 

   The Unified MPLS strategy - using MPLS from core to aggregation and
   access (e.g. IP/MPLS in the core, IP/MPLS or MPLS-TP in aggregation
   and access) appear to be very attractive to many SPs. It streamlines
   the operation, reduces the overall complexity, and improves end-to-
   end convergence. It leverages the MPLS experience, and enhances the
   ability to support revenue generating services.

   MPLS-TP is a subset of MPLS functions that meet the packet transport
   requirements defined in [RFC5654]. This subset includes: MPLS data
   forwarding, pseudo-wire encapsulation for circuit emulation, and
   dynamic control plane using GMPLS control for LSP and tLDP for
   pseudo-wire (PW). MPLS-TP also extends previous MPLS OAM functions,
   such as BFD extension for proactive Connectivity Check and
   Connectivity Verification (CC-CV) [RFC6428], and Remote Defect
   Indication (RDI) [RFC6428], LSP Ping Extension for on-demand CC-CV
   [RFC6426], fault allocation, and remote integrity check. New tools
   have been defined for alarm suppression with Alarm Indication Signal
   (AIS) [RFC6427], and switch-over triggering with Link Defect
   Indication (LDI). Note that since the MPLS OAM feature extensions
   defined through the process of MPLS-TP development are part of the
 

Fang et al.              Expires July 12, 2013                  [Page 3]
INTERNET DRAFT        MPLS-TP Use Cases and Design     December 16, 2012

   MPLS family, the applicability is general to MPLS, and not limited to
   MPLS-TP.

   The requirements of MPLS-TP are provided in MPLS-TP Requirements [RFC
   5654], and the architectural framework is defined in MPLS-TP
   Framework [RFC5921]. This document&Schaad, et al.              Standards Track                     [Page 4]
RFC 4055       Additional RSA Algorithms and Identifiers       June 2005

   If the keyUsage extension is present in a certificate conveys an RSA
   public key with the id-RSAES-OAEP object identifier, then the
   keyUsage extension MUST contain only the following values:

      keyEncipherment; and
      dataEncipherment.

   However, both keyEncipherment and dataEncipherment SHOULD NOT be
   present.

   When a certificate that conveys an RSA public key with the
   id-RSAES-OAEP object identifier, the certificate user MUST only use
   the certified RSA public key for RSAES-OAEP operations, and, if
   RSAES-OAEP-params is present, the certificate user MUST perform those
   operations using the one-way hash function and mask generation
   function identified in the subject public key algorithm identifier
   parameters within the certificate.

2.  Common Functions

   The RSASSA-PSS signature and the RSAES-OAEP key transport algorithms
   make use of one-way hash functions and mask generation functions.

2.1.  One-way Hash Functions

   PKCS #1 version 2.1 [P1v2.1] supports four one-way hash functions for
   use with the RSASSA-PSS signature algorithm and the RSAES-OAEP key
   transport algorithm: SHA-1, SHA-256, SHA-384, and SHA-512 [SHA2].
   This document adds support for SHA-224 [SHA-224] with both the
   RSASSA-PSS and the RSAES-OAEP algorithms.  While support for
   additional one-way hash functions could be added in the future, no
   other one-way hash functions are supported by this specification.

   These one-way hash functions are identified by the following object
   identifiers:

      id-sha1  OBJECT IDENTIFIER  ::=  { iso(1)
                           identified-organization(3) oiw(14)
                           secsig(3) algorithms(2) 26 }
      id-sha224  OBJECT IDENTIFIER  ::=  {{ joint-iso-itu-t(2)
                           country(16) us(840) organization(1) gov(101)
                           csor(3) nistalgorithm(4) hashalgs(2) 4 }
      id-sha256  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
                           country(16) us(840) organization(1) gov(101)
                           csor(3) nistalgorithm(4) hashalgs(2) 1 }
      id-sha384  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
                           country(16) us(840) organization(1) gov(101)
                           csor(3) nistalgorithm(4) hashalgs(2) 2 }

Schaad, et al.              Standards Track                     [Page 5]
RFC 4055       Additional RSA Algorithms and Identifiers       June 2005

      id-sha512  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
                           country(16) us(840) organization(1) gov(101)
                           csor(3) nistalgorithm(4) hashalgs(2) 3 }

   There are two possible encodings for the AlgorithmIdentifier
   parameters field associated with these object identifiers.  The two
   alternatives arise from the loss of the OPTIONAL associated with the
   algorithm identifier parameters when the 1988 syntax for
   AlgorithmIdentifier was translated into the 1997 syntax.  Later the
   OPTIONAL was recovered via a defect report, but by then many people
   thought that algorithm parameters were mandatory.  Because of this
   history some implementations encode parameters as a NULL element
   while others omit them entirely.  The correct encoding is to omit the
   parameters field; however, when RSASSA-PSS and RSAES-OAEP were
   defined, it was done using the NULL parameters rather than absent
   parameters.

   All implementations MUST accept both NULL and absent parameters as
   legal and equivalent encodings.

   To be clear, the following algorithm identifiers are used when a NULL
   parameter MUST be present:

      sha1Identifier  AlgorithmIdentifier  ::=  { id-sha1, NULL }
      sha224Identifier  AlgorithmIdentifier  ::=  { id-sha224, NULL }
      sha256Identifier  AlgorithmIdentifier  ::=  { id-sha256, NULL }
      sha384Identifier  AlgorithmIdentifier  ::=  { id-sha384, NULL }
      sha512Identifier  AlgorithmIdentifier  ::=  { id-sha512, NULL }

2.2.  Mask Generation Functions

   One mask generation function is used with the RSASSA-PSS signature
   algorithm and the RSAES-OAEP key transport algorithm: MGF1 [P1v2.1].
   No other mask generation functions are supported by this
   specification.

   MGF1 is identified by the following object identifier:

      id-mgf1  OBJECT IDENTIFIER  ::=  { pkcs-1 8 }

   The parameters field associated with id-mgf1 MUST have a
   hashAlgorithm value which identifies the hash function being used
   with MGF1.  This value MUST be sha1Identifier, sha224Identifier,
   sha256Identifier, sha384Identifier, or sha512Identifier, as specified
   in Section 2.1.  Implementations MUST support the default value,
   sha1Identifier, and MAY support the other four values.

Schaad, et al.              Standards Track                     [Page 6]
RFC 4055       Additional RSA Algorithms and Identifiers       June 2005

   The following algorithm identifiers have been assigned for each of
   these alternatives:

      mgf1SHA1Identifier  AlgorithmIdentifier  ::=
                           { id-mgf1, sha1Identifier }
      mgf1SHA224Identifier  AlgorithmIdentifier  ::=
                           { id-mgf1, sha224Identifier }
      mgf1SHA256Identifier  AlgorithmIdentifier  ::=
                           { id-mgf1, sha256Identifier }
      mgf1SHA384Identifier  AlgorithmIdentifier  ::=
                           { id-mgf1, sha384Identifier }
      mgf1SHA512Identifier  AlgorithmIdentifier  ::=
                           { id-mgf1, sha512Identifier }

3.  RSASSA-PSS Signature Algorithm

   This section describes the conventions for using the RSASSA-PSS
   signature algorithm with the Internet X.509 Certificate and CRL
   profile [PROFILE].  The RSASSA-PSS signature algorithm is specified
   in PKCS #1 version 2.1 [P1v2.1].  The five one-way hash functions
   discussed in Section 2.1 and the one mask generation function
   discussed in Section 2.2 can be used with RSASSA-PSS.

   CAs that issue certificates with the id-RSASSA-PSS algorithm
   identifier SHOULD require the presence of parameters in the
   publicKeyAlgorithms field if the cA boolean flag is set in the basic
   constraints certificate extension.  CAs MAY require that the
   parameters be present in the publicKeyAlgorithms field for end-entity
   certificates.

   CAs that use the RSASSA-PSS algorithm for signing certificates SHOULD
   include RSASSA-PSS-params in the subjectPublicKeyInfo algorithm
   parameters in their own certificates.  CAs that use the RSASSA-PSS
   algorithm for signing certificates or CRLs MUST include RSASSA-PSS-
   params in the signatureAlgorithm parameters in the TBSCertificate or
   TBSCertList structures.

   Entities that validate RSASSA-PSS signatures MUST support SHA-1.
   They MAY also support any other one-way hash functions in Section
   2.1.

   The data to be signed (e.g., the one-way hash function output value)
   is formatted for the signature algorithm to be used.  Then, a private
   key operation (e.g., RSA decryption) is performed to generate the
   signature value.  This signature value is then ASN.1 encoded as a BIT
   STRING and included in the Certificate or CertificateList in the
   signatureValue field.  Section 3.2 specifies the format of RSASSA-PSS
   signature values.

Schaad, et al.              Standards Track                     [Page 7]
RFC 4055       Additional RSA Algorithms and Identifiers       June 2005

3.1.  RSASSA-PSS Public Keys

   When RSASSA-PSS is used in an AlgorithmIdentifier, the parameters
   MUST employ the RSASSA-PSS-params syntax.  The parameters may be
   either absent or present when used as subject public key information.
   The parameters MUST be present when used in the algorithm identifier
   associated with a signature value.

   When signing, it is RECOMMENDED that the parameters, except for
   possibly saltLength, remain fixed for all usages of a given RSA key
   pair.

      id-RSASSA-PSS  OBJECT IDENTIFIER  ::=  { pkcs-1 10 }

      RSASSA-PSS-params  ::=  SEQUENCE  {
         hashAlgorithm      [0] HashAlgorithm DEFAULT
                                   sha1Identifier,
         maskGenAlgorithm   [1] MaskGenAlgorithm DEFAULT
                                   mgf1SHA1Identifier,
         saltLength         [2] INTEGER DEFAULT 20,
         trailerField       [3] INTEGER DEFAULT 1  }

   The fields of type RSASSA-PSS-params have the following meanings:

      hashAlgorithm

         The hashAlgorithm field identifies the hash function.  It MUST
         be one of the algorithm identifiers listed in Section 2.1, and
         the default hash function is SHA-1.  Implementations MUST
         support SHA-1 and MAY support any of the other one-way hash
         functions listed in Section 2.1.  Implementations that perform
         signature generation MUST omit the hashAlgorithm field when
         SHA-1 is used, indicating that the default algorithm was used.
         Implementations that perform signature validation MUST
         recognize both the sha1Identifier algorithm identifier and an
         absent hashAlgorithm field as an indication that SHA-1 was
         used.

      maskGenAlgorithm

         The maskGenAlgorithm field identifies the mask generation
         function.  The default mask generation function is MGF1 with
         SHA-1.  For MGF1, it is strongly RECOMMENDED that the
         underlying hash function be the same as the one identified by
         hashAlgorithm.  Implementations MUST support MGF1.  MGF1
         requires a one-way hash function that is identified in the
         parameters field of the MGF1 algorithm identifier.
         Implementations MUST support SHA-1 and MAY support any of the

Schaad, et al.              Standards Track                     [Page 8]
RFC 4055       Additional RSA Algorithms and Identifiers       June 2005

         other one-way hash functions listed in section Section 2.1.
         The MGF1 algorithm identifier is comprised of the id-mgf1
         object identifier and a parameter that contains the algorithm
         identifier of the one-way hash function employed with MGF1.
         The SHA-1 algorithm identifier is comprised of the id-sha1
         object identifier and an (optional) parameter of NULL.
         Implementations that perform signature generation MUST omit the
         maskGenAlgorithm field when MGF1 with SHA-1 is used, indicating
         that the default algorithm was used.

         Although mfg1SHA1Identifier is defined as the default value for
         this field, implementations MUST accept both the default value
         encoding (i.e., an absent field) and mfg1SHA1Identifier to be
         explicitly present in the encoding.

      saltLength

         The saltLength field is the octet length of the salt.  For a
         given hashAlgorithm, the recommended value of saltLength is the
         number of octets in the hash value.  Unlike the other fields of
         type RSASSA-PSS-params, saltLength does not need to be fixed
         for a given RSA key pair; a different value could be used for
         each RSASSA-PSS signature generated.

      trailerField

         The trailerField field is an integer.  It provides
         compatibility with IEEE Std 1363a-2004 [P1363A].  The value
         MUST be 1, which represents the trailer field with hexadecimal
         value 0xBC.  Other trailer fields, including the trailer field
         composed of HashID concatenated with 0xCC that is specified in
         IEEE Std 1363a, are not supported.  Implementations that
         perform signature generation MUST omit the trailerField field,
         indicating that the default trailer field value was used.
         Implementations that perform signature validation MUST
         recognize both a present trailerField field with value 1 and an
         absent trailerField field.

   If the default values of the hashAlgorithm, maskGenAlgorithm, and
   trailerField fields of RSASSA-PSS-params are used, then the algorithm
   identifier will have the following value:

      rSASSA-PSS-Default-Identifier  AlgorithmIdentifier  ::=  {
                           id-RSASSA-PSS, rSASSA-PSS-Default-Params }

      rSASSA-PSS-Default-Params RSASSA-PSS-Params ::= {
                           sha1Identifier, mgf1SHA1Identifier, 20, 1}

Schaad, et al.              Standards Track                     [Page 9]
RFC 4055       Additional RSA Algorithms and Identifiers       June 2005

3.2.  RSASSA-PSS Signature Values

   The output of the RSASSA-PSS signature algorithm is an octet string,
   which has the same length in octets as the RSA modulus n.

   Signature values in CMS [CMS] are represented as octet strings, and
   the output is used directly.  However, signature values in
   certificates and CRLs [PROFILE] are represented as bit strings, and
   conversion is needed.

   To convert a signature value to a bit string, the most significant
   bit of the first octet of the signature value SHALL become the first
   bit of the bit string, and so on through the least significant bit of
   the last octet of the signature value, which SHALL become the last
   bit of the bit string.

3.3.  RSASSA-PSS Signature Parameter Validation

   Three possible parameter validation scenarios exist for RSASSA-PSS
   signature values.

   1.  The key is identified by the rsaEncryption algorithm identifier.
       In this case no parameter validation is needed.

   2.  The key is identified by the id-RSASSA-PSS signature algorithm
       identifier, but the parameters field is absent.  In this case no
       parameter validation is needed.

   3.  The key is identified by the id-RSASSA-PSS signature algorithm
       identifier and the parameters are present.  In this case all
       parameters in the signature structure algorithm identifier MUST
       match the parameters in the key structure algorithm identifier
       except the saltLength field.  The saltLength field in the
       signature parameters MUST be greater or equal to that in the key
       parameters field.

4.  RSAES-OAEP Key Transport Algorithm

   This section describes the conventions for using the RSAES-OAEP key
   transport algorithm with the Internet X.509 Certificate and CRL
   profile [PROFILE].  RSAES-OAEP is specified in PKCS #1 version 2.1
   [P1v2.1].  The five one-way hash functions discussed in Section 2.1
   and the one mask generation function discussed in Section 2.2 can be
   used with RSAES-OAEP.  Conforming CAs and applications MUST support
   RSAES-OAEP key transport algorithm using SHA-1.  The other four one-
   way hash functions MAY also be supported.

Schaad, et al.              Standards Track                    [Page 10]
RFC 4055       Additional RSA Algorithms and Identifiers       June 2005

   CAs that issue certificates with the id-RSAES-OAEP algorithm
   identifier SHOULD require the presence of parameters in the
   publicKeyAlgorithms field for all certificates.  Entities that use a
   certificate with a publicKeyAlgorithm value of id-RSA-OAEP where the
   parameters are absent SHOULD use the default set of parameters for
   RSAES-OAEP-params.  Entities that use a certificate with a
   publicKeyAlgorithm value of rsaEncryption SHOULD use the default set
   of parameters for RSAES-OAEP-params.

4.1.  RSAES-OAEP Public Keys

   When id-RSAES-OAEP is used in an AlgorithmIdentifier, the parameters
   MUST employ the RSAES-OAEP-params syntax.  The parameters may be
   either absent or present when used as subject public key information.
   The parameters MUST be present when used in the algorithm identifier
   associated with an encrypted value.

      id-RSAES-OAEP  OBJECT IDENTIFIER  ::=  { pkcs-1 7 }

      RSAES-OAEP-params  ::=  SEQUENCE  {
         hashFunc          [0] AlgorithmIdentifier DEFAULT
                                  sha1Identifier,
         maskGenFunc       [1] AlgorithmIdentifier DEFAULT
                                  mgf1SHA1Identifier,
         pSourceFunc       [2] AlgorithmIdentifier DEFAULT
                                  pSpecifiedEmptyIdentifier  }

      pSpecifiedEmptyIdentifier  AlgorithmIdentifier  ::=
                           { id-pSpecified, nullOctetString }

      nullOctetString  OCTET STRING (SIZE (0))  ::=  { ''H }

   The fields of type RSAES-OAEP-params have the following meanings:

      hashFunc

         The hashFunc field identifies the one-way hash function.  It
         MUST be one of the algorithm identifiers listed in Section 2.1,
         and the default hash function is SHA-1.  Implementations MUST
         support SHA-1 and MAY support other one-way hash functions
         listed in Section 2.1.  Implementations that perform encryption
         MUST omit the hashFunc field when SHA-1 is used, indicating
         that the default algorithm was used.  Implementations that
         perform decryption MUST recognize both the sha1Identifier
         algorithm identifier and an absent hashFunc field as an
         indication that SHA-1 was used.

Schaad, et al.              Standards Track                    [Page 11]
RFC 4055       Additional RSA Algorithms and Identifiers       June 2005#x27;s intent is to provide the use
   case studies and design considerations from a practical point of view
   based on Service Providers deployments plans and actual deployments.

   The most common use cases for MPLS-TP include Metro access and
   aggregation, Mobile Backhaul, and Packet Optical Transport. MPLS-TP
   data plane architecture, path protection mechanisms, and OAM
   functionality are used to support these deployment scenarios. 

   The design considerations discussed in this documents include: role
   of MPLS-TP in the network; provisioning options; standards
   compliance; end-to-end forwarding and OAM consistency; compatibility
   with existing IP/MPLS networks; and optimization vs. simplicity
   design trade-offs.

2. Terminology

      Term     Definition
      ------   ------------------------------------------------------- 
      2G       2nd generation wireless telephone technology 
      3G       3rd generation of mobile telecommunications technology
      4G       4th Generation Mobile network: LTE 
      ADSL     Asymmetric Digital Subscriber Line 
      AIS      Alarm Indication Signal
      ASNGW    Access Service Network Gateway
      ATM      Asynchronous Transfer Mode
      BFD      Bidirectional Forwarding Detection
      BTS      Base Transceiver Station
      CC-CV    Continuity Check and Connectivity Verification
      CDMA     Code Division Multiple Access
      E-LINE   Ethernet point-to-point connectivity
      E-LAN    Ethernet LAN, provides multipoint connectivity
      eNB      Evolved Node B
      EPC      Evolved Packet Core
      E-VLAN   Ethernet Virtual Private LAN
      EVDO     Evolution-Data Optimized 
      G-ACh    Generic Associated Channel
      GAL      G-ACh Label
      GMPLS    Generalized Multi-Protocol Label Switching
      GSM      Global System for Mobile Communications
      HSPA     High Speed Packet Access
      IPTV     Internet Protocol television
      L2VPN    Layer 2 Virtual Private Network
 

Fang et al.              Expires July 12, 2013                  [Page 4]
INTERNET DRAFT        MPLS-TP Use Cases and Design     December 16, 2012

      L3VPN    Layer 3 Virtual Private Network
      LAN      Local Access Network
      LDI      Link Down Indication
      LDP      Label Distribution Protocol
      LSP      Label Switched Path
      LTE      Long Term Evolution
      MEP      Maintenance End Point
      MIP      Maintenance Intermediate Point
      NMS      Network Management System
      MPLS     MultiProtocol Label Switching
      MPLS-TP  MultiProtocol Label Switching Transport Profile
      MS-PW    Multi-Segment Pseudowire
      OAM      Operations, Administration, and Management
      OPEX     Operating Expenses
      PE       Provider-Edge device
      PSW      Packet Data Network Gateway
      RAN      Radio Access Network
      RDI      Remote Defect Indication
      S1       LTE Standardized interface between eNB and EPC 
      SDH      Synchronous Digital Hierarchy
      SGW      Serving Gateway
      SLA      Service Level Agreement
      SONET    Synchronous Optical Network 
      S-PE     PW Switching Provider Edge   
      SP       Service Provider
      SRLG     Shared Risk Link Groups
      SS-PW    Single-Segment Pseudowire
      TDM      Time Division Multiplexing
      tLDP     Targeted Label Distribution Protocol
      VPN      Virtual Private Network
      UMTS     Universal Mobile Telecommunications System 
      X2       LTE Standardized interface between eNBs for handover

3. MPLS-TP Use Cases

3.1. Metro Access and Aggregation 

   The use of MPLS-TP for Metro access and aggregation transport is the
   most common deployment scenario observed in the field. 

   Some operators are building green-field access and aggregation
   transport infrastructure, while others are upgrading/replacing their
   existing transport infrastructure with new packet technologies. The
   existing legacy access and aggregation networks are usually based on
   TDM or ATM technologies. Some operators are replacing these networks
   with MPLS-TP technologies, since legacy ATM/TDM aggregation and
   access are becoming inadequate to support the rapid business growth
 

Fang et al.              Expires July 12, 2013                  [Page 5]
INTERNET DRAFT        MPLS-TP Use Cases and Design     December 16, 2012

   and too expensive to maintain. In addition, in many cases the legacy
   devices are facing End of Sale and End of Life issues. As operators
   must move forward with the next generation packet technology, the
   adoption of MPLS-TP in access and aggregation becomes a natural
   choice. The statistical multiplexing in MPLS-TP helps to achieve
   higher efficiency comparing with the time division scheme in the
   legacy technologies. MPLS-TP OAM tools and protection mechanisms help
   to maintain high reliability of transport network and achieve fast
   recovery.

   As most Service Providers core networks are MPLS enabled, extending
   the MPLS technology to the aggregation and access transport networks
   with a Unified MPLS strategy is very attractive to many Service
   Providers. Unified MPLS strategy in this document means having end-
   to-end MPLS technologies through core, aggregation, and access. It
   reduces OPEX by streamlining operation and leveraging the operational
   experience already gained with MPLS technologies; it also improves
   network efficiency and reduces end-to-end convergence time. 

   The requirements from the SPs for ATM/TDM aggregation replacement
   often include: i) maintaining the previous operational model, which
   means providing a similar user experience in NMS, ii) supporting the
   existing access network, (e.g., Ethernet, ADSL, ATM, TDM, etc.), and
   connections with the core networks, and iii) supporting the same
   operational capabilities and services (L3VPN, L2VPN, E-LINE/E-LAN/E-
   VLAN, Dedicated Line, etc.). MPLS-TP can meet these requirements and
   in general the requirements defined in [RFC5654] to support a smooth
   transition.  

3.2. Packet Optical Transport 

   Many SP's transport networks consist of both packet and optical
   portions. The transport operators are typically sensitive to network
   deployment cost and operational simplicity. MPLS-TP supports both
   static provisioning through NMS and dynamic provisioning via the
   GMPLS control plane. As such, it is viewed as a natural fit in some
   of the transport networks, where the operators can utilize the MPLS-
   TP LSP's (including the ones statically provisioned) to manage user
   traffic as "circuits" in both packet and optical networks, and when
   they are ready, move to dynamic control plane for greater efficiency.

   Among other attributes, bandwidth management, protection/recovery and
   OAM are critical in Packet/Optical transport networks. In the context
   of MPLS-TP, each LSP is expected to be associated with a fixed amount
   of bandwidth in terms of bits-per-second and/or time-slots. OAM is to
   be performed on each individual LSP. For some of the performance
   monitoring (PM) functions, the OAM mechanisms need to be able to
   transmit and process OAM packets at very high frequency. An overview
 

Fang et al.              Expires July 12, 2013                  [Page 6]
INTERNET DRAFT        MPLS-TP Use Cases and Design     December 16, 2012

   of MPLS-TP OAM toolset is found in [RFC6669].

   Protection [RFC6372] is another important element in transport
   networks. Typically, ring and linear protection can be readily
   applied in metro networks. However, as long-haul networks are
   sensitive to bandwidth cost and tend to have mesh-like topology,
   shared mesh protection is becoming increasingly important. 

   In some cases, SPs plan to deploy MPLS-TP from their long haul
   optical packet transport all the way to the aggregation and access in
   their networks. 

3.3. Mobile Backhaul 

   Wireless communication is one of the fastest growing areas in
   communication worldwide. In some regions, the tremendous mobile
   growth is fueled by the lack of existing land-line and cable
   infrastructure. In other regions, the introduction of smart phones is
   quickly driving mobile data traffic to become the primary mobile
   bandwidth consumer (some SPs have already observed more than 85% of
   total mobile traffic are data traffic). MPLS-TP is viewed as a
   suitable technology for Mobile backhaul. 

3.3.1. 2G and 3G Mobile Backhaul 

   MPLS-TP is commonly viewed as a very good fit for 2G/3G mobile
   backhaul. 2G (GSM/CDMA) and 3G (UMTS/HSPA/1xEVDO) Mobile Backhaul
   Networks are still currently dominating the mobile infrastructure. 

   The connectivity for 2G/3G networks is point to point (P2P). The
   logical connections are hub-and-spoke. Networks are physically
   constructed using a star or ring topology. In the Radio Access
   Network (RAN), each mobile Base Transceiver Station (BTS/Node B) is
   communicating with a Radio Controller (BSC/RNC). These connections
   are often statically set up.  

   Hierarchical or centralized architectures are often used for pre-
   aggregation and aggregation layers. Each aggregation network inter-
   connects with multiple access networks. For example, a single
   aggregation ring could aggregate traffic for 10 access rings with
   total 100 base stations.   

   The technology used today is largely ATM based. Mobile providers are
   replacing the ATM RAN infrastructure with newer packet technologies.
   IP RAN networks with IP/MPLS technologies are deployed today by many
   SPs with great success. MPLS-TP is another suitable choice for Mobile
   RAN. The P2P connections from base station to Radio Controller can be
   set statically to mimic the operation of today's RAN environments;
 

Fang et al.              Expires July 12, 2013                  [Page 7]
INTERNET DRAFT        MPLS-TP Use Cases and Design     December 16, 2012

   in-band OAM and deterministic path protection can support fast
   failure detection and switch-over to satisfy the SLA agreements.
   Bidirectional LSPs may help to simplify the provisioning process. The
   deterministic nature of MPLS-TP LSP set up can also support packet
   based synchronization to maintain predictable performance regarding
   packet delay and jitters. 

3.3.2. 4G/LTE Mobile Backhaul 

   One key difference between LTE and 2G/3G mobile networks is that the
   logical connection in LTE is a mesh, while in 2G/3G is a P2P star. In
   LTE, the base stations eNB/BTS communicate with multiple Network
   controllers (PSW/SGW or ASNGW), and the radio elements communicate
   with one another for signal exchange and traffic offload to wireless
   or wireline infrastructures. 

   IP/MPLS has a great advantage in any-to-any connectivity environment.
   Thus, the use of mature IP or L3VPN technologies is particularly
   common in the design of SP's LTE deployment plans.

   The extended OAM functions defined in MPLS-TP, such as in-band OAM
   and path protection mechanisms bring additional advantages to support
   SLAs. The dynamic control-plane with GMPLS signaling is especially
   suited for the mesh environment, to support dynamic topology changes
   and network optimization.

   Some operators are using the similar model as in 2G and 3G Mobile
   Backhaul, which uses IP/MPLS in the core, and MPLS-TP with static
   provisioning through NMS in aggregation and access. The reasoning is
   the following: X2 traffic load in LTE network is currently a very
   small percentage, e.g., some large mobile operator observed less than
   one percent of total S1 traffic. Therefore, optimizing X2 traffic is
   not the design objective, X2 traffic can be carried through the same
   static tunnels together with S1 traffic in the aggregation and access
   networks, and further forwarded accross IP/MPLS core. In addition,
   Mesh protection may be more efficient in regard of bandwidth
   utilization, but linear protection and ring protection are considered
   simpler by some operators from operation maintenance and trouble
   shooting point of view, therefore widely deployed. In general, using
   MPLS-TP with NMS model for LTE backhaul is a viable approach. The
   design objective of using this approach is to keep the operation
   simple and with unified model for mobile backhaul. 

4. Network Design Considerations  

4.1. The role of MPLS-TP

   The role of MPLS-TP is to provide a solution to help evolving
 

Fang et al.              Expires July 12, 2013                  [Page 8]
INTERNET DRAFT        MPLS-TP Use Cases and Design     December 16, 2012

   traditional transport towards packet. It is designed to support the
   transport characteristics/behavior described in [RFC5654]. The
   primary use of MPLS-TP is largely to replace legacy transport
   technologies, such as SONET/SDH. MPLS-TP is not designed to replace
   the service support capabilities of IP/MPLS, such as L2VPN, L3VPN,
   IPTV, Mobile RAN, etc. 

4.2. Provisioning mode

   MPLS-TP supports two provisioning modes: i) a mandatory static
   provisioning mode, which must be supported without dependency on
   dynamic routing or signaling; and ii) an optional distributed dynamic
   control plane, which is used to enable dynamic service provisioning.

   The decision on which mode to use is largely dependent on the
   operational feasibility and the stage of evolution transition.
   Operators who are accustomed with the transport-centric operational
   model (e.g., NMS configuration without control plane) typically
   prefer the static provisioning mode. This is the most common choice
   in current deployments. The dynamic provisioning mode can be more
   powerful but it is more suited for operators who are familiar with
   the operation and maintenance of IP/MPLS technologies or ready to
   step up through training and planned transition. 

   There may be also cases where operators choose to use the combination
   of both modes. This is appropriate when parts of the network are
   provisioned in a static fashion and other parts are controlled by
   dynamic signaling. This combination may also be used to transition
   from static provisioning to dynamic control plane.   

4.3. Standards compliance 

   It is generally recognized by SPs that standards compliance is
   important for lowering cost, accelerating product maturity, achieving
   multi-vendor interoperability, and meeting the expectations of their
   enterprise customers. 

   MPLS-TP is a joint work between IETF and ITU-T. In April 2008, IETF
   and ITU-T jointly agreed to terminate T-MPLS and progress MPLS-TP as
   joint work [RFC5317]. The transport requirements are provided by ITU-
   T, the protocols are developed in IETF.  

4.4. End-to-end MPLS OAM consistency 

   End-to-end MPLS OAM consistency is highly desirable in order to
   enable Service Providers to deploy end-to-end MPLS solution with a
   combination of IP/MPLS (for example, in the core including service
 

Fang et al.              Expires July 12, 2013                  [Page 9]
INTERNET DRAFT        MPLS-TP Use Cases and Design     December 16, 2012

   edge) and MPLS-TP (for example, in the aggregation/access networks).
   Using MPLS based OAM in MPLS-TP can help achieving such a goal. 

4.5. PW Design considerations in MPLS-TP networks 

   In general, PWs in MPLS-TP work the same as in IP/MPLS networks. Both
   Single-Segment PW (SS-PW) and Multi-Segment PW (MS-PW) are supported.
   For dynamic control plane, Targeted LDP (tLDP) is used. In static
   provisioning mode, PW status is a new PW OAM feature for failure
   notification. In addition, both directions of a PW must be bound to
   the same transport bidirectional LSP. 

   In the common network topology involving multi-tier rings, the design
   choice is between using SS-PW or MS-PW. This is not a discussion
   unique to MPLS-TP, as it applies to PW design in general, but it is
   relevant here, since MPLS-TP is more sensitive to the operational
   complexities, as noted by operators. If MS-PW is used, Switched PE
   (S-PE) must be deployed to connect the rings. The advantage of this
   choice is that it provides domain isolation, which in turn
   facilitates trouble shooting and allows for faster PW failure
   recovery. On the other hand, the disadvantage of using S-PE is that
   it adds more complexity. Using SS-PW is simpler, since it does not
   require S-PEs, but less efficient because the paths across primary
   and secondary rings are longer. If operational simplicity is a higher
   priority, some SPs choose the latter. 

   Another design trade-off is whether to use PW protection in addition
   to LSP protection or rely solely on LSP protection. By definition,
   MPLS-TP LSPs are protected. If the working LSP fails, the protect LSP
   assures that the connectivity is maintained and the PW is not
   impacted. However, in the case of simultaneous failure of both
   working and protect LSPs, the attached PW would fail. By adding PW
   protection, and attaching the protect PW to a diverse LSP not in the
   same Shared Risk Link Group (SRLG), the PW is protected even when the
   primary PW fails.  Clearly, using PW protection adds considerably
   more complexity and resource usage, and thus operators often may
   choose not to use it, and consider protection against single point of
   failure as sufficient. 

4.6. Proactive and on-demand MPLS-TP OAM tools 

   MPLS-TP provide both proactive and on-demand OAM Tools. As a
   proactive OAM fault management tool, BFD hellos can be sent at
   regular intervals for Connectivity Check; 3 missed hellos trigger the
   failure protection switch-over. BFD sessions are configured for both
   working and protecting LSPs. 

   A design decision is choosing the value of the BFD hello interval.
 

Fang et al.              Expires July 12, 2013                 [Page 10]
INTERNET DRAFT        MPLS-TP Use Cases and Design     December 16, 2012

   The shorter the interval (3.3ms is the minimum allowed interval), the
   faster the detection time is, but also the higher the resource
   utilization is. The proper value depends on the application and the
   service needs.

   As an on-demand OAM fault management mechanism, for example when
   there is a fiber cut, Link Down Indication (LDI) message [RFC6427] is
   generated from the failure point and propagated to the Maintenance
   End Points (MEPs) to trigger immediate switch-over from working to
   protect path. An Alarm Indication Signal (AIS) propagates from the
   Maintenance Intermediate Point (MIP) to the MEPs for alarm
   suppression.

   In general, both proactive and on-demand OAM tools should be enabled
   to guarantee short switch-over times. 

4.7. MPLS-TP and IP/MPLS Interworking considerations  

   Since IP/MPLS is largely deployed in most SPs' networks, MPLS-TP and
   IP/MPLS interworking is a reality.  

   The interworking issues are addressed in a separate document
   [Interworking].

5. Security Considerations 

   Under the use case of Metro access and aggregation, in the scenario
   where some of the access equipment is placed in facilities not owned
   by the SP, the static provisioning mode of MPLS-TP is often preferred
   over the control plane option because it eliminates the possibility
   of a control plane attack which may potentially impact the whole
   network. This scenario falls into the Security Reference Model 2 as
   described in [MPLS-TP Sec FW].

   Similar location issues apply to the mobile use cases, since
   equipment is often placed in remote and outdoor environment, which
   can increase the risk of un-authorized access to the equipment. 

   In general, NMS access can be a common point of attack in all MPLS-TP
   use cases, and attacks to GAL or G-ACh are unique security treats to
   MPLS-TP. The MPLS-TP security considerations are discussed in MPLS-TP
   Security Framework [MPLS-TP Sec FW]. General security considerations
   for MPLS and GMPLS networks are addressed in Security Framework for
   MPLS and GMPLS Networks [RFC5920].  

6. IANA Considerations 

   This document contains no new IANA considerations. 
 

Fang et al.              Expires July 12, 2013                 [Page 11]
INTERNET DRAFT        MPLS-TP Use Cases and Design     December 16, 2012

7. Acknowledgements

   The authors wish to thank Adrian Farrel for his review as Routing
   Area Director, Adrian's detailed comments were of great help for
   improving the quality of this document, and thank Loa Andersson for
   his continued support and guidance. The authors would also like to
   thank Weiqiang Cheng for his helpful input on LTE Mobile backhaul
   based on his knowledge and experience in real world deployment.

8. References

8.1. Normative References

   [RFC5317]  Bryant, S., Ed., and L. Andersson, Ed., "Joint Working
              Team (JWT) Report on MPLS Architectural Considerations for
              a Transport Profile", RFC 5317, February 2009.

   [RFC5654]  Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
              Sprecher, N., and S. Ueno, "Requirements of an MPLS
              Transport Profile", RFC 5654, September 2009.

   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, July 2010.

   [RFC6426]  Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
              On-Demand Connectivity Verification and Route Tracing",
              RFC 6426, November 2011.

   [RFC6427]  Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed.,
              Boutros, S., and D. Ward, "MPLS Fault Management
              Operations, Administration, and Maintenance (OAM)",
              RFC 6427, November 2011.

   [RFC6428]  Allan, D., Ed., Swallow Ed., G., and J. Drake Ed.,
              "Proactive Connectivity Verification, Continuity Check,
              and Remote Defect Indication for the MPLS Transport
              Profile", RFC 6428, November 2011.

8.2. Informative References

   [RFC5921]  Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
              L., and L. Berger, "A Framework for MPLS in Transport
              Networks", RFC 5921, July 2010.

   [RFC6372]  Sprecher, N., Ed., and A. Farrel, Ed., "MPLS Transport
              Profile (MPLS-TP) Survivability Framework", RFC 6372,
              September 2011.
 

Fang et al.              Expires July 12, 2013                 [Page 12]
INTERNET DRAFT        MPLS-TP Use Cases and Design     December 16, 2012

   [RFC6669]  Sprecher, N. and L. Fang, "An Overview of the Operations,
              Administration, and Maintenance (OAM) Toolset for MPLS-
              Based Transport Networks", RFC 6669, July 2012.

   [Interworking] Martinotti, R., et al., "Interworking between MPLS-TP 
              and IP/MPLS," draft-martinotti-mpls-tp-interworking-
              02.txt, June 2011.  

   [MPLS-TP Sec FW] Fang, L. Ed., Niven-Jenkins, B., Ed., Mansfield,  
              S., Ed., Graveman, R., Ed., "MPLS-TP Security Framework," 
              draft-ietf-mpls-tp-security-framework-05.txt, October
              2012.

Authors' Addresses

      Luyuan Fang 
      Cisco Systems, Inc. 
      111 Wood Ave. South 
      Iselin, NJ 08830
      United States
      Email: lufang@cisco.com                                                                         
      Nabil Bitar 
      Verizon 
      40 Sylvan Road 
      Waltham, MA 02145
      United States 
      Email: nabil.bitar@verizon.com 

      Raymond Zhang 
      Alcatel-Lucent  
      701 Middlefield Road 
      Mountain View, CA 94043
      United States 
      Email: raymond.zhang@alcatel-lucent.com

      Masahiro DAIKOKU 
      KDDI corporation 
      3-11-11.Iidabashi, Chiyodaku, Tokyo
      Japan    
      Email: ms-daikoku@kddi.com 

      Ping Pan
      Infinera
      United States
      Email: ppan@infinera.com

 

Fang et al.              Expires July 12, 2013                 [Page 13]
INTERNET DRAFT        MPLS-TP Use Cases and Design     December 16, 2012

Contributors' Addresses

      Kam Lee Yap 
      XO Communications 
      13865 Sunrise Valley Drive, 
      Herndon, VA 20171
      United States 
      Email: klyap@xo.com 

      Dan Frost 
      Cisco Systems, Inc.
      United Kingdom 
      Email:danfrost@cisco.com 

      Henry Yu 
      TW Telecom 
      10475 Park Meadow Dr. 
      Littleton, CO 80124
      United States
      Email: henry.yu@twtelecom.com 

      Jian Ping Zhang   China Telecom, Shanghai    
      Room 3402, 211 Shi Ji Da Dao 
      Pu Dong District, Shanghai
      China 
      Email: zhangjp@shtel.com.cn 

      Lei Wang  
      Lime Networks
      Strandveien 30, 1366 Lysaker
      Norway
      Email: lei.wang@limenetworks.no

      Mach(Guoyi) Chen 
      Huawei Technologies Co., Ltd. 
      No. 3 Xinxi Road 
      Shangdi Information Industry Base 
      Hai-Dian District, Beijing 100085 
      China 
      Email: mach@huawei.com 

      Nurit Sprecher  
      Nokia Siemens Networks 
      3 Hanagar St. Neve Ne'eman B 
      Hod Hasharon, 45241 
      Israel 
      Email: nurit.sprecher@nsn.com 

Fang et al.              Expires July 12, 2013                 [Page 14]