Internet DRAFT - draft-beeram-ccamp-gmpls-enni

draft-beeram-ccamp-gmpls-enni






 CCAMP Working Group                                   Igor Bryskin (Ed) 
 Internet Draft                                               Wes Doonan  
 Intended status: Standards Track                ADVA Optical Networking 
                                                Vishnu Pavan Beeram (Ed) 
                                                         John Drake (Ed) 
                                                            Gert Grammel 
                                                        Juniper Networks  
                                                             Manuel Paul 
                                                          Ruediger Kunze 
                                                        Deutsche Telekom 
                                                    Friedrich Armbruster 
                                                          Cyril Margaria 
                                                            Coriant GmbH 
                                                  Oscar Gonzalez de Dios  
                                                              Telefonica 
                                                      Daniele Ceccarelli  
                                                               Ericcsson 
                                                                                     
 Expires: March 12, 2014                              September 12, 2013 
                                         
      
                                         
                                           
     Generalized Multiprotocol Label Switching (GMPLS) External Network 
        Network Interface (E-NNI):  Virtual Link Enhancements for the 
                                Overlay Model 
                    draft-beeram-ccamp-gmpls-enni-03.txt 


 Status of this Memo 

    This Internet-Draft is submitted in full conformance with the 
    provisions of BCP 78 and BCP 79.  

    Internet-Drafts are working documents of the Internet Engineering 
    Task Force (IETF), 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 

    The list of Internet-Draft Shadow Directories can be accessed at 
    http://www.ietf.org/shadow.html 
      
      
  
      
 Beeram, et al           Expires March 12, 2014                 [Page 1] 
      

 Internet-Draft                GMPLS-ENNI                 September 2013 
         

    This Internet-Draft will expire on March 12, 2014. 

 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. 

 Abstract 

    This memo is a companion document to [RFC4208]. It describes how the 
    client domain networking in the overlay model can be enhanced via 
    presenting to the client the network domain as an overlay topology 
    made of Virtual TE Links.  

 Conventions used in this document 

    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 RFC-2119 [RFC2119]. 
      
 Table of Contents 

    1. Introduction...................................................3 
    2. Hybrid Topology................................................3 
    3. Traffic Engineering............................................7 
       3.1. Augmenting the Client layer Topology.....................11 
          3.1.1. Virtual TE Links....................................13 
       3.2. Macro SRLGs..............................................15 
       3.3. MELGs....................................................17 
       3.4. Switching Constraints....................................18 
    4. GMPLS ENNI and Multiple Server Network Domains................19 
    5. Path computation aspects......................................21 
    6. Access and Virtual TE link addressing.........................22 
    7. Use cases.....................................................22 
       7.1. Service Optimization and Restoration in Multi-layer networks
       ..............................................................22 
      
      
      
 Beeram, et al           Expires March 12, 2014                 [Page 2] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
         

       7.2. IP/MPLS Offloading with ENNI automation..................23 
       7.3. Use of PCE and VNTM in Multi-layer Network Operation.....24 
    8. Security Considerations.......................................25 
    9. IANA Considerations...........................................25 
    10. References...................................................25 
       10.1. Normative References....................................25 
       10.2. Informative References..................................25 
    11. Acknowledgments..............................................26 
         
 1. Introduction 

    [RFC4208] discusses how GMPLS can be applied to the overlay model, 
    which it defines to be a client network that uses a server network 
    to dynamically instantiate LSPs between the client network's nodes. 
    In the client network such an LSP is a link between two adjacent 
    client nodes, while in the server network the LSP may transit 
    multiple links and nodes; the client network is unaware of the 
    server network topology. 

    While the client network is unaware of the server network topology, 
    [RFC4208] does suggest that there may be an exchange of routing 
    information between the server network and the client network.  
    Building on this premise, this memo describes how introducing a 
    representation of server network domain resources into a client 
    network domain topology enhances client networking in the overlay 
    model 

    This document is designed to be a companion document to [RFC4208], 
    but because routing is generally not considered to be part of the 
    definition of a UNI, this document uses the term 'External Network 
    Network Interface (E-NNI)'. 'E-NNI' is generally used to indicate a 
    control plane (routing and signaling) reference point for exchange 
    of information between two control plane instances. In this 
    document, the term 'ENNI'is specifically used to describe the 
    interface between two network domains that allows the exchange of 
    routing and signaling information.  

 2. Hybrid Topology 

    Two adjacent domains in the overlay model represent, generally 
    speaking, regions of dissimilar transport technology. When an end-
    to-end service crosses a boundary between the domains, it is 
    necessary to execute distinct forms of service activation within 
    each domain.  


      
      
      
 Beeram, et al           Expires March 12, 2014                 [Page 3] 



 Internet-Draft                GMPLS-ENNI                 September 2013 
         

                     
                                       |       +---+ 
                                       |       |   |  - router node 
                    +---+              |       +---+ 
                    | B |              | 
                    +---+              |        /-\ 
                     /                 |       (   )  - WDM node 
                    /                  |        \-/ 
                   /                   |________________________________ 
                  / 
                 / 
               /-\          /-\           /-\          +---+ 
              ( E )--------( G )---------( J )---------| C | 
               \-/          \-/           \-/          +---+ 
                           /   \         /   \ 
                          /     \       /     \ 
                         /       \     /       \ 
                        /         \   /         \ 
                       /           \ /           \ 
      +---+          /-\           /-\           /-\          +---+ 
      | A |---------( F )---------( H )---------( I )---------| D | 
      +---+          \-/           \-/           \-/          +---+ 

                     Figure 1: Sample hybrid topology  

         

    For example, in the hybrid network illustrated in Fig 1, 
    provisioning a transport service between two GMPLS-enabled IP 
    routers (clients) on either side of the optical WDM transport 
    topology (server network domain) requires operations in two distinct 
    layer networks; the client layer network interconnecting the routers 
    themselves, and the server layer network interconnecting the optical 
    transport elements in between the routers.  

    The activation of the end-to-end service begins with a path 
    determination process, followed by the initiation of a signaling 
    process from the ingress client network element along the determined 
    path, per the example illustrated in Fig 2a-c. 

      

      
      
      
 Beeram, et al           Expires March 12, 2014                 [Page 4] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
         

      

                 
                   
       
                    +---+ 
                    | B |        |      
                    +---+        |  ##### - client-layer service 
                     /           |  ***** - server-layer WDM service 
                    /            |_____________________________________ 
                   / 
                  / 
                 / 
               /-\          /-\           /-\          +---+ 
              ( E )--------( G )---------( J )---------| C | 
               \-/          \-/           \-/          +---+ 
                           /   \         /   \ 
                          /     \       /     \ 
                         /       \     /       \ 
                        /         \   /         \ 
                       /           \ /           \ 
      +---+ ######## /-\           /-\           /-\          +---+ 
      | A |---------( F )---------( H )---------( I )---------| D | 
      +---+          \-/           \-/           \-/          +---+ 
      
                    
               Figure 2a: Hierarchical service activation - 
                          Client-layer service setup is initiated. 
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
 Beeram, et al           Expires March 12, 2014                 [Page 5] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
         

      
      
      
      
      
      
      
                    +---+ 
                    | B |        | 
                    +---+        |  ##### - client-layer service 
                     /           |  ***** - server-layer WDM service 
                    /            |_____________________________________ 
                   / 
                  / 
                 / 
               /-\          /-\           /-\          +---+ 
              ( E )--------( G )---------( J )---------| C | 
               \-/         *\-/*         *\-/          +---+ 
                          */   \*       */   \ 
                         */     \*     */     \ 
                        */       \*   */       \ 
                       */         \* */         \ 
                      */           \*/           \ 
      +---+ ######## /-\           /-\           /-\          +---+ 
      | A |---------( F )---------( H )---------( I )---------| D | 
      +---+          \-/           \-/           \-/          +---+ 
      
                    
           Figure 2b: Hierarchical service activation - 
                      Server-layer WDM service that caters to the 
                      client-layer service is established within the    
                      core. 
      
      
      
      
      
      
      
      
      
      
      
 Beeram, et al           Expires March 12, 2014                 [Page 6] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
         

      
      
      
      
                    +---+ 
                    | B |       | 
                    +---+       |   ##### - client-layer service 
                     /          |   ***** - server-layer WDM service 
                    /           |____________________________________ 
                   / 
                  / 
                 / 
               /-\          /-\           /-\ ######## +---+ 
              ( E )--------( G )---------( J )---------| C | 
               \-/        #*\-/*#       #*\-/          +---+ 
                         #*/   \*#     #*/   \ 
                        #*/     \*#   #*/     \ 
                       #*/       \*# #*/       \ 
                      #*/         \*#*/         \ 
                     #*/           \*/           \ 
      +---+ ######## /-\           /-\           /-\          +---+ 
      | A |---------( F )---------( H )---------( I )---------| D | 
      +---+          \-/           \-/           \-/          +---+ 
      
           Figure 2c: Hierarchical service activation - 
                      Client-layer service setup is resumed and 
                      the end-to-end connection is established. 
                                              
                    

 3. Traffic Engineering 

    The previous section outlines the basic method for activating end-
    to-end services across a multi-domain/multi-layer network.  As a 
    necessary part of that process an initial path selection process is 
    to be performed, whereby an appropriate path between the desired 
    endpoints is to be determined through some means. Further, per 
    expectations set through current practices with regard to service 
    provisioning in homogeneous networks, operators expect that the 
    underlying control plane system provides automated mechanisms for 
    computing the desired path(s) between network endpoints.   

     
      
      
 Beeram, et al           Expires March 12, 2014                 [Page 7] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
         

    In particular, operators do not expect under normal circumstances to 
    be required to explicitly specify the end-to-end path; rather, they 
    expect to be able to specify just the endpoints of the path and rely 
    on an automated computational process to identify and qualify all 
    the elements and links on the path between them.  Hence when 
    operating a hybrid multi-layer network such as that described in Fig 
    1, it is necessary to extend existing traffic engineering and path 
    computation mechanisms to operate in a similar manner. 

    Path computation and qualification operations occur at the path 
    computation element (PCE - RFC4655) selected by ingress network 
    element of an end-to-end service. In order to be able to compute and 
    qualify paths, the PCE should be provided with information regarding 
    the traffic engineering capabilities of the layer network to which 
    it is associated with, in particular, the topology of the layer 
    network and what layer-specific transport capabilities exist at the 
    various nodes and links in that topology. 

    It is important to note that topology information is layer-specific; 
    e.g. path computation and qualification operations occur within a 
    given layer, and hence information about topology and resource 
    availability are required for the specific layer to which the 
    connection belongs. The topology and resource availability 
    information required by a path computation element in the client 
    layer is quite distinct from that required by a path computation 
    element in the server layer network. Hence, the actual server layer 
    traffic engineering links are of no importance for the client layer 
    network. In fact, it can be desirable to block their advertisements 
    into the client TE domain by the border nodes. 

    For example, in the sample hybrid network (Fig 1) there are multiple 
    transport elements supporting client the connection (in this memo 
    terms "connection" and "LSP" are used interchangeably) between the 
    GMPLS-enabled clients A and C, the server layer topology between 
    them includes several nodes and links.  However, in this example the 
    optical network elements are not capable of switching traffic with 
    the client layer granularity (i.e. IP/MPLS packets), as the optical 
    network elements are lambda switches, not IP/MPLS switches.  Hence, 
    while the intervening server layer network elements may physically 
    exist along the path, they are not a part of the topology required 
    by the client layer nodes for the purposes of traffic engineering in 
    the client layer network. 

    An example of what the client layer Traffic Engineering topology 
    would look like for the sample hybrid network is shown in the top 
    half of Fig 3. 
     
      
      
 Beeram, et al           Expires March 12, 2014                 [Page 8] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
         

                                  |  +++++ - client-layer TE link        
                                  |  ~~~~~ - server-layer TE link 
                                  |  =====    
                                  |  | N | - client-layer TE node (only)  
   Client TE        =====         |  =====  
   Database         | B |         |   {N}  - server-layer TE node (only)     
                    =====         |  =====  
                     +            |  |{N}| - server and client-layer             
                    +             |  =====   TE node 
                   +              |_____________________________________    
                  +                   
              =====                  =====         ===== 
              |{E}|~~~~~~~~~{G}~~~~~~|{J}|+++++++++| C | 
              =====         ~ ~      =====         ===== 
                           ~   ~     ~   ~ 
                          ~     ~   ~     ~ 
                         ~       ~ ~       ~ 
      =====         =====         ~       =====         ===== 
      | A |++++++++ |{F}|~~~~~~~~{H} ~~~~~|{I}|+++++++++| D | 
      =====         =====                 =====         ===== 
      
       
   Physical        +---+       | 
   Topology        | B |       | ##### - client-layer service 
                   +---+       | ***** - server-layer WDM service 
                   /           |__________________________________ 
                  / 
                 / 
               /-\          /-\       /-\ ######## +---+ 
              ( E )--------( G )-----( J )---------| C | 
               \-/        #*\-/*#   #*\-/          +---+ 
                         #*/   \*# #*/   \ 
                        #*/     \*#*/     \ 
                       #*/       \*/       \ 
      +---+ ########## /-\       /-\       /-\          +---+ 
      | A |-----------( F )-----( H )-----( I )---------| D | 
      +---+            \-/       \-/       \-/          +---+ 
     
           Figure 3: Traffic engineering - ERO with "loose hop" 
                     [Path = {A,F,J,C} (with J loose)]. 
      
      
      
 Beeram, et al           Expires March 12, 2014                 [Page 9] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
         

                      
         
    In this example, the TE topology associated with the client layer 
    network is indicated by the links marked with '+' and nodes marked 
    without brackets, whereas the TE topology associated with the server 
    layer network is indicated by the links marked with '~' and nodes 
    marked in '{}'.  The nodes at the edge of the server layer network 
    are visible in both the topologies. The client topology is capable 
    of switching traffic within the client layer, whereas the server 
    topology is capable of switching traffic within the server layer.  

    In this example, if the "B" router attempts to determine a path to 
    the "D" router it will be unable to do so, as the client topology to 
    which the B and D routers is connected does not include a full path 
    made of just client layer links between them. The only way to setup 
    an end-to-end path in this case is to use an ERO with a "loose hop" 
    across the server layer domain as illustrated in Fig 3. This would 
    cause the server layer to create the necessary link in the client 
    layer topology on the fly. However, this approach has a few 
    drawbacks - [a] the necessity for the operator to specify the ERO 
    with the "loose" hop; [b] potential sub-optimal usage of server 
    layer network resources; [c] unpredictability with regard to the 
    fate-sharing of the new link (that is created on the fly) with other 
    links of the client layer topology.  

    In order to be able to compute an end-to-end path between the two 
    client layer endpoints, the client topology must be sufficiently 
    augmented to indicate where there are paths through the server 
    topology, which can provide connectivity between nodes in the client 
    topology. In other words, in order for a client to compute path(s) 
    across the server layer network to other clients, the feasible paths 
    across the server layer network should be made available (in terms 
    of TE links and nodes that exist in the client layer network) to all 
    the clients. This is discussed in detail in the next section. 

    As it is mentioned already, in the overlay model the client and 
    network domains, generally speaking, exist in separate layer- 
    networks. One important use case, however, is when the client and 
    network topologies belong to the same layer network. For example, IP 
    routers, connected via GMPLS ENNI to a WDM network, could be capable 
    of terminating optical trails being lambda switched by the network.  
    The method described in the following sections allows also 
    partitioning a single layer network into domains. Those domains do 
    not need to leak the full routing information to their neighboring 
    domains but rather provide sufficient information for a path 
      
      
      
 Beeram, et al           Expires March 12, 2014                [Page 10] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
         

    computation engine to route connections across a multi-domain 
    network. 

         

 3.1. Augmenting the Client layer Topology 

    In the example hybrid network, shown below in Fig 4, consider a 
    scenario, where each GMPLS-enabled IP router is connected to the 
    optical WDM transport network via a transponder.  Further, consider 
    the situation, where the transponder on node F can be connected to 
    the transponder on node J via the optical path F-G-H-J. Suppose, a 
    lambda LSP is provisioned in the server layer along this path and 
    advertised (as a TE link) into the client layer network. With the 
    availability of this TE link, the path computation function at node  

      
   Client TE        =====           |  +++++ - client-layer TE link 
   Database         | B |           | 
                    =====           |  =====   client-layer 
                     +              |  | N | - TE node 
                    +               |  ===== 
                   +                |_________________________________    
                  + 
                 + 
              =====                      =====         ===== 
              |{E}|         {G}          |{J}|+++++++++| C | 
              =====                      =====         ===== 
                                     +++ 
                                   ++ 
                                ++ 
                              ++ 
                          +++ 
      =====         =====                       =====         ===== 
      | A |++++++++ |{F}|          {H}          |{I}|+++++++++| D | 
      =====         =====                       =====         ===== 
     
      
      
      
      
      
      
      
      
 Beeram, et al           Expires March 12, 2014                [Page 11] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
         

      
      
   Physical         +---+ 
   Topology         | B | 
                    +---+       | 
                     /          |  ***** - server-layer WDM service 
                    /           |____________________________________ 
                   / 
                  / 
                 / 
               /-\          /-\           /-\          +---+ 
              ( E )--------( G )---------( J )---------| C | 
               \-/         *\-/*         *\-/          +---+ 
                          */   \*       */   \ 
                         */     \*     */     \ 
                        */       \*   */       \ 
                       */         \* */         \ 
                      */           \*/           \ 
      +---+          /-\           /-\           /-\          +---+ 
      | A |---------( F )---------( H )---------( I )---------| D | 
      +---+          \-/           \-/           \-/          +---+ 
         
           Figure 4: Traffic engineering - end-to-end path          
                     computation.[The client layer "TE link" between F  
                     and J is produced by creating the underlying     
                     server-layer connection; Node A has visibility  
                     to end-to-end (A to C) client-layer links and  
                     can do CSPF] 
                                         
         
    A is able to compute an end-to-end path from A to C. In this 
    example, in order for the TE link to be made available in the client 
    layer network topology, the network resources supporting the 
    underlying server layer LSP are fully committed beforehand.  

    As another scenario, consider a network configuration, where the 
    transponders on nodes E, F, J and I are connected to each other via 
    directionless ROADM technology.  In this case it is physically 
    possible to connect any transponder to any other transponder in the 
    server layer network. As there are transport capabilities available 
    in the server layer network between every pair of elements with an 
    adaptation function to the client layer network, the operator in 
    
      
      
 Beeram, et al           Expires March 12, 2014                [Page 12] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
         

    this case would not wish to commit any network resources in the 
    server layer network until a client LSP is signaled. The next 
    section proposes a method to address this common operational 
    requirement.   

 3.1.1. Virtual TE Links 

    A "Virtual TE Link" as defined in section 7.3.3 of [RFC4847] is a TE 
    link that is advertised into the client layer network. The 
    advertisement includes information about available but not 
    necessarily reserved/committed resources in the server layer network 
    necessary to support that TE link.  In other words, Virtual TE Links 
    represent specific transport capabilities available in the server 
    layer network, which can support the establishment of LSPs in the 
    client layer network.  

    The two fundamental properties of a Virtual TE Link are: [a] it is 
    advertised just like a real TE link and thus contributes to the 
    buildup of the client layer network topology; and [b] it does not 
    require allocation of resources at the server layer until used, thus 
    allowing the mutually exclusive sharing of server layer network 
    resources with other Virtual TE Links. 

      
   Client TE        =====        |  +++++ - client-layer TE link 
   Database         | B |        | 
                    =====        |  =====   client-layer 
                     +           |  | N | - TE node 
                    +            |  ===== 
                   +             |____________________________________ 
                  + 
                 + 
              =====                      =====         ===== 
              |{E}|         {G}          |{J}|+++++++++| C | 
              =====                      =====         ===== 
                                     +++ 
                                  +++ 
                               +++ 
                             ++ 
                          +++ 
      =====         =====                       =====         ===== 
      | A |+++++++++|{F}|          {H}          |{I}|+++++++++| D | 
      =====         =====                       =====         ===== 
  
      
      
 Beeram, et al           Expires March 12, 2014                [Page 13] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
         

      
      
      
      
   Physical         +---+ 
   Topology         | B |       | 
                    +---+       |  *-*-* - potential server-layer 
                     /          |          WDM service 
                    /           |______________________________________ 
                   / 
                  / 
                 / 
               /-\          /-\           /-\          +---+ 
              ( E )--------( G )---------( J )---------| C | 
               \-/         -\-/-         -\-/          +---+ 
                          */   \*       */   \ 
                         -/     \-     -/     \ 
                        */       \*   */       \ 
                       -/         \- -/         \ 
                      */           \*/           \ 
      +---+          /-\           /-\           /-\          +---+ 
      | A |---------( F )---------( H )---------( I )---------| D | 
      +---+          \-/           \-/           \-/          +---+ 
      
           Figure 5: Traffic engineering - end-to-end path     
                     computation with "Virtual TE Links". [The  
                     "Virtual TE link" between F and J is created   
                     in the client layer without actually    
                     instantiating the underlying server-layer  
                     connection; Node A has visibility to end- 
                     to-end client-layer links and can do CSPF] 
        

         

    In the example shown in Fig 5, the availability of a lambda channel 
    along the path F-G-H-J results in the advertisement by nodes F and J 
    of a Virtual TE Link between F and J into the client layer network 
    topology (+++ line).  With the advertisement of this Virtual TE 
    Link, the path computation function at node A is able to compute an 
    end-to-end path from A to C. 

     
      
      
 Beeram, et al           Expires March 12, 2014                [Page 14] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
         

    Whenever a Virtual TE Link gets selected and signaled in the ERO of 
    a client layer LSP, it ceases temporarily to be "virtual" and 
    transforms into a regular TE link. When this transformation takes 
    place, the clients will notice the change in the advertised 
    available bandwidth of this TE link. Also, all other Virtual TE 
    Links that share in a mutual exclusive way some of server layer 
    resources with the TE link in question SHOULD start advertising 
    "zero" available bandwidth. Likewise, the TE network image reverts 
    back to the original form as soon as the last client layer LSP, 
    going through the TE link in question, is released, i.e. Virtual TE 
    Link becomes "virtual" again. 

    The overlay topology, advertised into the client domain as a set of 
    Virtual TE Links, along with access TE links (the TE links 
    interconnecting client network elements with the network domain) 
    makes up the topology that in the overlay model allows for the 
    client domain path computation function to compute end-to-end paths 
    interconnecting client network elements across the network domain. 

 3.2. Macro SRLGs 

    The Virtual TE Links, which are advertised into the client layer 
    network topology, cannot be assumed to be independent. It is quite 
    possible for a given Virtual TE Link to share fate with one or more 
    other Virtual TE Link(s). This is because the underlying server 
    layer LSPs (established or potential) can traverse the same server 
    layer network link and/or node, and failure of any such shared 
    link/node would make all such LSPs inoperable (along with the 
    Virtual TE Links supported by the LSPs). If diverse end-to-end paths 
    for client layer LSPs are to be computed, the fate sharing 
    information of the Virtual TE Links needs to be taken into account. 
    The standard way of addressing this problem is via the concept of 
    Shared Risk Link Group (SRLG). Specifically, a network resource 
    shared by two or more TE links is identified via a network scope 
    unique number (SRLG ID) and advertised within each such TE link 
    advertisement.  

    A "traditional" SRLG (per [RFC4202]) represents a shared physical 
    network resource, upon which normal function of a link depends. Such 
    SRLGs can also be referred to as physical SRLGs.  Zero, one or more 
    physical SRLGs could be identified and advertised for every TE link 
    in a given layer network. There is a scalability issue with physical 
    SRLGs in multi-layer environments. For example, if a server layer 
    LSP serves a client layer link, every server layer link and node 
    traversed by the LSP must be considered as a separate SRLG. The 
    number of server layer SRLGs to be advertised to client layer per 
    
      
      
 Beeram, et al           Expires March 12, 2014                [Page 15] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
        

    TE link is directly proportional to the number of hops traversed by 
    the underlying server layer LSP. 

    This document introduces a notion of Macro SRLGs, which addresses 
    this scaling problem. Macro SRLGs have the same protocol format as 
    their physical counterparts and can be assigned automatically for 
    each TE link that is advertised into the client layer network 
    supported by an underlying server layer LSP (instantiated or 
    otherwise). A Macro SRLG represents a shared path segment that is 
    traversed by two or more of the underlying server layer LSPs. Each 
    shared path segment can be viewed as a set of shared server layer 
    resources. The actual procedure for deriving the Macro SRLGs is 
    beyond the scope of this document. 

    
   Client TE        =====        |   +25+ - client-layer TE link 
   Database         | B |        |          with SRLG ID "25" 
                    =====        |__________________________________ 
                     + 
                    + 
                   + 
                  + 
                 + 
              =====                      =====         ===== 
              |{E}|         {G}          |{J}|+++++++++| C | 
              =====                      =====         ===== 
                   ++25++             +++ 
                          +++++    +++ 
                               ++++ 
                             ++     +++++ 
                         +25+            +++++++ 
      =====         =====                       =====         ===== 
      | A |+++++++++|{F}|          {H}          |{I}|+++++++++| D | 
      =====         =====                       =====         ===== 
      
      
      
      
      
      
      
      
      
      
      
 Beeram, et al           Expires March 12, 2014                [Page 16] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
         

                    +---+ 
                    | B | 
                    +---+         ***** - F-J WDM service 
                     /            @@@@@ - E-I WDM service 
                    / 
                   / 
                  / 
                 / 
               /-\ @@@@@@@@ /-\           /-\          +---+ 
              ( E )--------( G )---------( J )---------| C | 
               \-/         *\-/*@       @*\-/@         +---+ 
                          */   \*@     @*/   \@ 
                         */     \*@   @*/     \@ 
                        */       \*@ @*/       \@ 
                       */         \*@*/         \@ 
                      */           \*/           \@ 
      +---+          /-\           /-\           /-\          +---+ 
      | A |---------( F )---------( H )---------( I )---------| D | 
      +---+          \-/           \-/           \-/          +---+ 
   
           Figure 6: Macro SRLGs - ["TE links" E-I and F-J share fate 
                     since the underlying server-layer connections  
                     traverse the same path segments [G-H][H-I]. Macro  
                     SRLG-ID "25" is assigned to both "TE links"] 
 3.3. MELGs 

    If two or more Virtual TE Links share fate, it means that the links 
    could be concurrently activated and used by client LSPs with a 
    caveat that the links could be taken out of service by a single 
    network failure, and, thus, cannot be used in the same protection 
    scheme. There could be a stronger (than fate sharing) relationship 
    between two or more Virtual TE Links. Because a set of Virtual TE 
    Links can depend on the same uncommitted network resources, the 
    situation can arise, when only one Virtual TE Link from the set 
    could be activated at any given time. In other words, two or more 
    Virtual TE Links can be mutually exclusive.  

    One example of the mutually exclusive relationship of Virtual TE 
    Links is when the paths for the server layer network LSPs supporting 
    the Virtual TE Links not only intersect, but also require usage of 
    the same resource (e.g. lambda channel) on the intersection. Another 
    example is when the said paths depend on a common physical resource 

     
      
      
 Beeram, et al           Expires March 12, 2014                [Page 17] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
         

    (e.g. transponder, regenerator, wavelength converter, etc.) that 
    could be used only by one LSP at a time. 

    For a client path computation function (especially a centralized one 
    capable of concurrent computation of multiple paths) it is important 
    to know about such mutually exclusive relationship between Virtual 
    TE Links. This document recommends the use of the extensions defined 
    in [MELG] to address this requirement. 

        
 3.4. Switching Constraints 

    Generally speaking, it SHOULD NOT be assumed that a Virtual TE Link 
    advertised by a given network domain border node can be cross-
    connected within a client LSP with every access TE link advertised 
    by the said node. This circumstance necessitates the specification 
    of connectivity constraints by network domain border nodes. If such 
    information is not available for client domain path computers, there 
    is a significant risk of provisioning failures of client LSPs, 
    if/when they are signaled with the computed paths (see, Figure 7). 
    This document recommends the use of the advertisements specified in 
    [GEN_CNSTR] and [OSPF_GEN_CONSTR] to address the network element 
    switching limitations problem. 

      +---+-a1------b1--/-\--b3--------------c1--/-\--c3-----d1-+---+ 
      | A |            ( B )                    ( C )           | D | 
      +---+-a2------b2--\-/--b4--------------c2--\-/--c4-----d2-+---+ 
    
      
 Access TE-links:       TE links served           Valid paths: 
                        By the server domain: 
 a1-b1, c3-d1           b3-c1                     [a1-b1][b3-c1][c3-d1] 
 a2-b2, c4-d2           b4-c2                     [a2-b2][b4-c2][c4-d2] 
  
      
 Binding constraints:                             Invalid paths: 
 b1<->b3                                          [a1-b1][b4-c2]... 
 b2<->b4                                          [a2-b2][b3-c1]... 
 c1<->c3                                          [a1-b1][b3-c1][c4-d2] 
 c2<->c4                                          [a2-b2][b4-c2][c3-d1] 
      
                       Figure 7: Switching Constraints 
         
      
      
      
 Beeram, et al           Expires March 12, 2014                [Page 18] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
        

 4. GMPLS ENNI and Multiple Server Network Domains 

    In the previous sections a single server network domain GMPLS ENNI 
    configuration was considered. The said configuration is modeled as a 
    set of client nodes, belonging to one or more client domains, 
    connected to a single server network domain. The connectivity is 
    realized via access links in the data plane and GMPLS ENNI 
    interfaces in the control plane. The server domain is independent 
    from the client domain(s) (administratively and from the Traffic 
    Engineering and control/management plane point of view). The network 
    domain exposes its resources to the clients in a form of Virtual TE 
    Links, thus, enabling the clients to influence the way their LSPs 
    are routed across the network domain. 

    There are important use cases that require client LSPs to traverse 
    more than one server network domains. In such use cases the server 
    domains, generally speaking, are independent from each other and 
    from each of the client domains. In such configurations the clients 
    would still want to control the routing of their LSPs in each of the 
    server domains, the LSPs are going through, for the same reasons it 
    is necessary to do so in the single server domain configuration 
    (e.g. diversity, fate sharing, MELG considerations, etc.). 
    Fortunately, the Virtual TE Link approach allows for exposing of the 
    resources of multiple network domains in the same way as in the 
    single server domain case, and, thus, provides the same tools for 
    dynamic provisioning of client LSPs across either single or multiple 
    server network domains.  

    Multiple server network domains are modeled as separate independent 
    networks interconnected with each other on their respective border 
    nodes via inter-domain links in the data plane and GMPLS ENNI 
    interfaces in the control plane. A network border node sees no 
    difference between an access link and an inter-domain link 
    terminated on the node (nor can it tell whether it is connected via 
    a given link to a client node or a border node of a neighboring 
    server network domain). Just like in the single-domain case, each 
    server domain exposes its resources to other server and client 
    network domains via Virtual TE Links configured in accordance with 
    local domain policies. It is responsibility of server domain border 
    nodes to advertise into the neighboring domains all access, inter-
    domain and Virtual TE Links it locally terminates, as well as 
    imposed on them switching limitations. The said advertisements are 
    flooded into the client domains and populate the client path 
    computer's TEDs. Successful path computations produce end-to-end 
    paths in the form of access, Virtual and inter-domain TE link 
    chains. 
      
      
      
 Beeram, et al           Expires March 12, 2014                [Page 19] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
        

      Client TE                  |  +++++ - client-domain TE link 
      Database                   | 
                                 |  =====    
                                 |  | N | - client-domain TE node 
                                 |  ===== 
                                 |____________________________________ 
                                 
                                                     
                         {G}                 {K} 
                              
                    
                                
         =====     =====     =====     =====     =====     ===== 
         | A |+++++|{F}|+++++|{H}|+++++|{J}|+++++|{L}|+++++|{D}| 
         =====     =====     =====     =====     =====     ===== 
      
         
         
                         {I}                 {M} 
         
      Physical          
      Topology                   | 
                                 |  *-*-* - potential server-layer 
                                 |          WDM service 
                                 |___________________________________ 
  
        
                         /-\                 /-\ 
                        ( G )               ( K ) 
                        -\-/-               -\-/- 
                       */   \*             */   \* 
                      -/     \-           -/     \- 
                     */       \*         */       \* 
         +---+      /-\       /-\       /-\       /-\      +---+ 
         | A |-----( F )     ( H )-----( J )     ( L )-----| B | 
         +---+      \-/       \-/       \-/       \-/      +---+ 
                      \       /           \       / 
                       \     /             \     / 
                        \   /               \   / 
                         /-\                 /-\ 
                        ( I )               ( M )  
                         \-/                 \-/   

        Figure 8: Multiple Network Domains ([F,G,H,I] belong to Server 
        Network Domain 1;[J,K,L,M] belong to Server Network domain 2) 

      
      
      
 Beeram, et al           Expires March 12, 2014                [Page 20] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
         

 5. Path computation aspects 

    It is assumed that a client domain path computation function makes 
    use of advertised access TE links as well as Virtual TE Links, while 
    computing end-to-end paths for client LSPs. The said path 
    computation function could be local (i.e. located on client LSP 
    ingress nodes, as stipulated by [RFC4655] Composite PCE node) or 
    remote (i.e. on network PCEs). Path computations could be triggered 
    by client nodes or NMS. Generally speaking, the responsibility of 
    the client domain path computation function is to (concurrently) 
    compute one or several paths for each source-destination pair 
    (potential client LSP termination points) specified in a single path 
    computation request. The path computation SHOULD be subject to one 
    or more path optimization criterions (such as minimal cost, minimal 
    latency, etc.) and a set of path computation constraints (such as 
    link unreserved bandwidth, link colors, layer-specific constraints, 
    explicit inclusions and exclusions, etc.) 

    As the overlay topology hides actual server domain/layer links and 
    nodes, it is RECOMMENDED to support SRLG diverse computation of two 
    or more paths. 

    Furthermore, the path computation SHOULD consider the 
    connectivity/switching limitation constraint (when available) in 
    addition to all other path computation constraints. 

    The use of the PCE architecture and PCEP protocol is governed by 
    [RFC5440], [RFC5521] and [RFC5541].  

    As described in section 3.3., two or more Virtual TE Links may not 
    only share risk, but also may exclusively depend on the same server 
    layer resources. Therefore, paths, computed on network topologies 
    containing Virtual TE Links, have an increased probability of LSP 
    setup failures (two LSPs, for example, could be routed over two 
    Virtual TE Links that exclusively depend on the same server layer 
    resource). In such cases concurrent path computation, taking in 
    consideration MELG information, will address this problem. PCEP 
    supports concurrent path computation per [RFC5440]. Specifying MELG 
    diversity constraint in path computation requests is out of scope of 
    this document.  

    In addition MELG may carry information on the establishment of 
    server-layer resources. A Path computation request MAY constraint 
    the path computation to TE-Links that are fully provisioned only. 
    This information MAY also be used in PCE path computation policies.   

    
      
      
 Beeram, et al           Expires March 12, 2014                [Page 21] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
         

 6. Access and Virtual TE link addressing 

    [RFC4208] implies that access TE links could be named from the same 
    address space as network domain TE links or from a separate address 
    space. This memo requires the following: 

    - It MAY be possible to assign addresses for access TE links from 
      the same address space as the one used for naming network internal 
      TE links (i.e. TE links interconnecting network domain devices); 
    - It MUST be possible to assign addresses for access TE links from a 
      separate address space, independent from the space used for 
      addressing network internal TE links; 
    - Virtual TE Links MUST share the address space with any access TE 
      links they are allowed to be cross-connected within a client LSP.  

       

 7. Use cases 

 7.1. Service Optimization and Restoration in Multi-layer networks 

      
    Multi-layer networks are a reality today, and they are operated by 
    different groups of people, following different operational 
    procedures. This requires an independent optimization of the client 
    and server layer networks. Such independence may cause a situation, 
    where the re-routing of a client layer LSP fails, because some of 
    resources on the selected alternate path share fate with some of 
    resources on the LSP's failed path.  This usually happens due to 
    lack of knowledge of the server layer network by a client layer path 
    computation function at the time when the alternative path is 
    selected. 

    The high volume and importance of IP traffic in provider networks 
    today requires the client and server layer networks to share 
    sufficient information in order to enable an optimized transport for 
    IP/MPLS services and address existing inefficiencies. From the 
    carrier perspective it is very important that the SRLG information 
    is provided by the server layer TE application and is used by the 
    client layer path computation. 

    In a typical multi-layer network, where IP/MPLS is the client layer 
    network and WDM/OTN is the server layer network, the client layer 
    network is responsible for the protection of the IP/MPLS traffic 
    from networks failures. This is normally achieved via using 

     
      
      
 Beeram, et al           Expires March 12, 2014                [Page 22] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
         

    protection schemes, such as FRR and/or LFA.  Regardless of the used 
    mechanism, the SRLG information, provided by the server layer 
    network, helps to optimize the client layer network with respect to 
    reduced link utilization and reliable and efficient protection of 
    the user traffic. 

    Today the SRLGs information is used mainly when calculating diverse 
    alternative paths for the IP/MPLS LSPs. Therefore, the following 
    procedures are performed periodically: 

    - Building traffic matrix for the server layer network  
      (based on IP links) 
    - Solving traffic engineering problems in the server layer network 
    - (Re-)Calculating SRLGs to be propagated into the client layer  
      network 
    - Simulating failure scenarios 
    - Making sure that the affected IP/MPLS LSPs function properly after 
      they are replaced onto SRLG diverse alternative paths 
       

    GMPLS ENNI reduces the OPEX costs of performing these procedures via 
    the automation as follows: 

    - server layer network automatically discovers and advertises the 
      SRLG information into client layer network via a common routing 
      protocol; 

    - client layer network path computer uses the SRLG information when 
      selecting diverse paths.  
       
 7.2. IP/MPLS Offloading with ENNI automation 

    A typical application in multi-layer (IP/MPLS over optical) networks 
    is termed 'IP Offloading', in which the network responds to the 
    increase in traffic of a particular service or across a segment in 
    the IP network by dynamically creating additional IP/MPLS links 
    served by GMPLS LSPs provisioned in the server layer network, and 
    placing the extra IP/MPLS traffic onto said links. Likewise, when 
    the IP/MPLS traffic decreases to a normal pattern, the said GMPLS 
    LSPs are torn down, and the extra IP/MPLS links are removed from the 
    client layer network TE domain. The increase in traffic is typically 
    caused by an elevated number of high traffic flows/services 
    traversing an IP network segment.   


      
      
      
 Beeram, et al           Expires March 12, 2014                [Page 23] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
         

    The decision process driving IP offloading is complex, and is 
    governed by a set of rules. These rules reduce the cost of running 
    the multi-layer network, while ensuring that it remains stable.  

    Automation of IP Offloading poses a number of challenges. It 
    includes dynamic provisioning, release and maintenance of GMPLS LSPs 
    in the server layer (e.g. WDM) network as well as automatic 
    advertising/withdrawing them as (numbered or/and unnumbered) TE 
    links into/from the client layer network. In order to pre-plan and 
    manage properly the said dynamic IP/MPLS TE links, it is important 
    to know in advance (and also in real time) the capabilities and 
    resource availability of server layer network. The network 
    domain/layer virtualization procedures described in this document 
    helps to solve this complex operational issue. 

          

 7.3. Use of PCE and VNTM in Multi-layer Network Operation 

    Two key elements have been proposed to help in the management and 
    coordination of multi-layer networks: the Path Computation Element 
    (PCE) and the Virtual Network Topology Manager (VNTM). PCE is 
    responsible for the calculation of paths between endpoints, 
    particularly in complex scenarios involving, for example, WDM layer 
    physical impairments.  VNTM is in charge of maintaining the topology 
    of the client layer network by instantiating virtual links, in the 
    server layer network.  I.e., it can be used to provide TE links to 
    the client layer network dynamically. 

    Several cooperation modes between PCE, VNTM and the NMS have been 
    proposed in [RFC5623]. For instance, the operator can request a new 
    MPLS tunnel via the NMS, which communicates with a PCE with 
    information of the multi-layer network. The PCE, in case there are 
    enough resources in the IP/MPLS layer, normally returns a path for 
    the tunnel made of real TE links. On the other hand, if there is a 
    lack of resources in the IP/MPLS layer, the response may contain a 
    path with one or more Virtual TE Links. In this case, the NMS can 
    cooperate with the VNTM to suggest the set-up of a GMPLS LSP(s) in 
    the server layer network. The VNTM, based on the local policies, can 
    accept the suggestion and cause the set-up of the GMPLS LSPs in the 
    server layer network. 

    In order for the computation to be effective, the PCE needs 
    knowledge of the overlay topology (SRLGs, MELGs, TE metrics of the 
    Virtual TE links), which can be provided via GMPLS ENNI.  

     
      
      
 Beeram, et al           Expires March 12, 2014                [Page 24] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
        

 8. Security Considerations 

    TBD 

 9. IANA Considerations 

    TBD. 

 10. References 

 10.1. Normative References 

    [RFC2119]        Bradner, S., "Key words for use in RFCs to Indicate 
                     Requirement Levels", BCP 14, RFC 2119, March 1997. 
       
    [RFC4202]        K. Kompella, Y.Rekhter 
                     "Routing Extensions in Support of Generalized   
                     Multi-Protocol Label Switching (GMPLS)",  
                     RFC 4202, October 2005. 
               
    [RFC4208]        G. Swallow, J.Drake, H. Ishimatsu, and Y. Rekhter, 
                     "GMPLS UNI: RSVP-TE Support for the Overlay Model",  
                     RFC 4208, October 2005. 
       
    [GEN_CNSTR]      G.Bernstein, Y.Lee, D.Li, W.Imajuku, "General  
                     Network Element Constraint Encoding for GMPLS  
                     Controlled Networks"  
                     [draft-general-constraint-encode-10.txt] 
        
    [OSPF_GEN_CNSTR] F.Zhang, J.Han, Y.Lee, D.Li, G.Bernstein, Y.Hu               
                     "OSPF-TE Extensions for General Network Element          
                     Constraints"
                     [draft-general-constraints-ospf-te-04.txt] 
         
    [MELG]           V.Beeram, I.Bryskin, et al, "Mutually Exclusive 
                     Link Groups", [draft-beeram-ccamp-melg-01.txt] 
                     
    [TE INFO XCHG]   A.Farrel, N.Bitar, G.Swallow, D.Ceccarelli,  
                     "Problem Statement and Architecture for Information  
                     Exchange Between Interconnected Traffic Engineered 
                     Networks", [draft-farrel-interconnected-te-info- 
                     exchange-01.txt]   
         
 10.2. Informative References 

    [RFC4847]        T. Takeda, "Framework and Requirements for Layer 1  
     
      
      
 Beeram, et al           Expires March 12, 2014                [Page 25] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
         

                     VPNs", RFC 4847, April 2007. 
         
    [RFC4655]        A. Farrel, J.-P. Vasseur, J. Ash, "A Path  
                     Computation Element (PCE)-Based Architecture", RFC  
                     4655, August 2006. 
      
         
 11. Acknowledgments 

    Chris Bowers [cbowers@juniper.net]  
         
 Authors' Addresses 
    Igor Bryskin 
    ADVA Optical Networking 
       
    Email: ibryskin@advaoptical.com 
        
         
    Wes Doonan 
    ADVA Optical Networking 
         
    Email: wdoonan@advaoptical.com 
         
         
    Vishnu Pavan Beeram 
    Juniper Networks 
         
    Email:vbeeram@juniper.net 
         
         
    John Drake 
    Juniper Networks 
         
    Email: jdrake@juniper.net 
         
         
    Gert Grammel 
    Juniper Networks 
         
    Email: ggrammel@juniper.net 
         
         
    Manuel Paul 
    Deutsche Telekom 
         
    Email: Manuel.Paul@telekom.de 
      
      
      
 Beeram, et al           Expires March 12, 2014                [Page 26] 
 






 Internet-Draft                GMPLS-ENNI                 September 2013 
         

         
         
    Ruediger Kunze 
    Deutsche Telekom 
         
    Email: Ruediger.Kunze@telekom.de 
         
         
    Oscar Gonzalez de Dios  
    Telefonica 
        
    Email: ogondio@tid.es 
         
         
    Cyril Margaria 
    Coriant GmbH 
         
    Email: cyril.margaria@coriant.com 
         
            
    Friedrich Armbruster 
    Coriant GmbH 
        
    Email: friedrich.armbruster@coriant.com 
            
    Daniele Ceccarelli 
    Ericsson 
         
    Email: daniele.ceccarelli@ericsson.com 
      
















      
      
      
 Beeram, et al           Expires March 12, 2014                [Page 27]