Skip to main content

Applicability of Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI)
draft-zhang-ccamp-gmpls-uni-app-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Fatai Zhang , Oscar Gonzalez de Dios , Adrian Farrel , Xian Zhang , Daniele Ceccarelli
Last updated 2013-02-21
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-zhang-ccamp-gmpls-uni-app-03
Network Working Group                                        Fatai Zhang 
Internet Draft                                                    Huawei 
Category: Informational                              O. Gonzalez de Dios 
                                   Telefonica Investigacion y Desarrollo        
                                                               A. Farrel 
                                                      Old Dog Consulting 
                                                              Xian Zhang  
                                                                  Huawei 
                                                           D. Ceccarelli 
                                                                Ericsson 
Expires: August 21, 2013                               February 22, 2013 
                                    
                                    
                                    
   Applicability of Generalized Multiprotocol Label Switching (GMPLS) 
                      User-Network Interface (UNI) 
                                    
                  draft-zhang-ccamp-gmpls-uni-app-03.txt 

Status of this Memo 

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

   Internet-Drafts are working documents of the Internet Engineering   
   Task Force (IETF), its areas, and its working groups.  Note that   
   other groups may also distribute working documents as Internet-   
   Drafts. 

   Internet-Drafts are draft documents valid for a maximum of six months   
   and may be updated, replaced, or obsoleted by other documents at any   
   time.  It is inappropriate to use Internet-Drafts as reference   
   material or to cite them other than as "work in progress." 

   The list of current Internet-Drafts can be accessed at   
   http://www.ietf.org/ietf/1id-abstracts.txt. 

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

   This Internet-Draft will expire on August 21, 2013. 

    

Abstract 
 

 
 
 
Zhang                   Expires August 2013                  [Page 1] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

   Generalized Multiprotocol Label Switching (GMPLS) defines a set of 
   protocols for the creation of Label Switched Paths (LSPs) in various 
   switching technologies. The GMPLS User-Network Interface (UNI) was 
   developed in RFC4208 in order to be applied to an overlay network 
   architectural model.  

   This document examines a number of GMPLS UNI application scenarios. 
   It shows how techniques developed after the GMPLS UNI can be applied 
   to automate or enable critical processes for these applications. This 
   document also suggests simple extensions that could be made to 
   existing technologies to further enable the UNI and points out some 
   unresolved issues.   

    

Table of Contents 

   1. Introduction ................................................ 3 
   2. UNI Addressing .............................................. 5 
   3. UNI Auto Discovery .......................................... 6 
   4. UNI Path Computation......................................... 7 
      4.1. UNI Link Selection...................................... 8 
   5. UNI Path Provisioning........................................ 9 
      5.1. Flat Model ............................................. 9 
      5.2. Stitching Model........................................ 10 
      5.3. Session Shuffling Model................................ 11 
      5.4. Hierarchal Model....................................... 11 
   6. UNI Recovery ............................................... 12 
      6.1. End-to-end Recovery.................................... 12 
         6.1.1. Serial Provisioning of Working and Protection Paths 13 
         6.1.2. Concurrent Computation of Working and Protection Path14 
      6.2. Segment Recovery....................................... 14 
   7. UNI Call ................................................... 15 
      7.1. Exchange of UNI Link Information ....................... 15 
      7.2. Control of Call Route.................................. 16 
   8. UNI Multicast .............................................. 16 
      8.1. UNI Multicast Connection Model ......................... 17 
      8.2. UNI Multicast Connection Provisioning .................. 18 
   9. Security Considerations..................................... 19 
   10. IANA Considerations........................................ 19 
   11. Acknowledgments ........................................... 19 
   12. References ................................................ 20 
      12.1. Normative References.................................. 20 
      12.2. Informative References................................ 22 
   13. Contributors' Address...................................... 23 
   14. Authors' Addresses ........................................ 23 

 
 
Zhang                   Expires August 2013                  [Page 2] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

 
1. Introduction 

   Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] defines a 
   set of protocols, including Open Shortest Path Fist - Traffic 
   Engineering (OSPF-TE) [RFC4203] and Resource ReserVation Protocol - 
   Traffic Engineering (RSVP-TE) [RFC3473], which can be used to create 
   Label Switched Paths (LSPs) in a number of deployment scenarios with 
   various transport technologies.  

   The User-Network Interface (UNI) reference point is defined in the 
   Automatically Switched Optical Network (ASON) [G.8080]. According to 
   [G.8080], the UNI may be implemented as a peering between a client-
   side entity (UNI-C) and a network-side entity (UNI-N). End-to-end 
   connectivity between UNI-C nodes is achieved across the core network 
   by three components: a UNI request from source UNI-C to source UNI-N; 
   a core network connection from source UNI-N to destination UNI-N; and 
   a UNI request from destination UNI-N to destination UNI-C. 

   The GMPLS overlay model, as per [RFC4208], can be applied at the UNI, 
   as shown in Figure 1.  

     Overlay                                                  Overlay 
     Network       +----------------------------------+       Network 
   +---------+     |                                  |     +---------+ 
   |  +----+ |     |  +-----+    +-----+    +-----+   |     | +----+  | 
   |  |    | | UNI |  |     |    |     |    |     |   | UNI | |    |  | 
   | -+ EN1+-+-----+--+ CN1 +----+ CN2 +----+ CN3 +---+-----+-+ EN3+- | 
   |  |    | |  +--+--+     |    |     |    |     |   |     | |    |  | 
   |  +----+ |  |  |  +--+--+    +--+--+    +--+--+   |     | +----+  | 
   +---------+  |  |     |          |          |      |     +---------+ 
                |  |     |          |          |      | 
   +---------+  |  |  +--+--+       |       +--+--+   |     +---------+ 
   |  +----+ |  |  |  |     |       +-------+     |   |     | +----+  | 
   |  |    +-+--+  |  | CN4 +---------------+ CN5 |   |     | |    |  | 
   | -+ EN2+-+-----+--+     |               |     +---+-----+-+ EN4+- | 
   |  |    | | UNI |  +-----+               +-----+   | UNI | |    |  | 
   |  +----+ |     |                                  |     | +----+  | 
   +---------+     +----------------------------------+     +---------+ 
     Overlay                 Core Network                     Overlay 
     Network                                                  Network 

                       Legend:   EN  -  Edge Node 
                                 CN  -  Core Node 
    
              Figure 1 - Applying GMPLS overlay model at UNI 

 
 
Zhang                   Expires August 2013                  [Page 3] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

   In Figure 1, assume that there is an end-to-end UNI connection 
   passing through EN1-CN1-CN2-CN3-EN3. For convenience, some terms used 
   in this document are defined below: 

   -  "source EN" refers to the edge-node which initiates the 
      connection (i.e., EN1);  

   "destination EN" refers to the edge-node where the connection is 
   terminated (i.e., EN3); 

   -   "ingress CN" refers to the core-node to which the source EN is 
      attached (i.e., CN1);  

   -  "egress CN" refers to the core-node to which the destination EN 
      is attached (i.e., CN3). 

   [RFC4208] provides mechanisms for UNI signaling, which are compatible 
   with GMPLS RSVP-TE signaling ([RFC3471] and [RFC3473]). A single end-
   to-end RSVP session between source EN and destination EN is used for 
   the user connection, just as it would be for connection creation 
   between two core nodes. However, when considering the isolation of 
   topology information between the core network and the overlay network, 
   additional processing of the RSVP-TE Explicit Route Object (ERO) and 
   Record Route Object (RRO) is required. For example, the ingress CN 
   should verify the ERO it receives against its topology database and 
   may enhance it with additional path information before forwarding the 
   PATH message. And the ingress/egress CN may edit or remove the RRO in 
   order to hide the path segment used inside the core network from the 
   EN. 

   The GMPLS UNI can be used in many application scenarios. For example, 
   in a multi-layer network [RFC6001] the interface between client layer 
   node and server layer node can be seen as a UNI. Or, when deploying 
   VPN services such as Layer One Virtual Private Networks (L1VPNs) 
   [RFC4847], [RFC5253], users can connect to a service provider network 
   via a UNI. 

   This document examines a number of current and future GMPLS 
   application scenarios. It shows how techniques developed after the 
   GMPLS UNI can be used to automate or enable critical aspects of these 
   application scenarios. It points out some potential technology 
   extensions that could improve UNI operation, and highlights some 
   unresolved issues. 

    

 
 
Zhang                   Expires August 2013                  [Page 4] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

2. UNI Addressing 

   In [RFC4208], the GMPLS overlay model is applied at the UNI reference 
   point, and it is required that the edge-node and its attached core-
   node of the overlay network share the same address space that is used 
   by GMPLS to signal between the edge-nodes across the core network. 
   Under this condition, the user connection can be created using a 
   single end-to-end RSVP session, which is consistent with the RSVP 
   model. Therefore, RSVP-TE defined in [RFC3473] can be used for 
   support GMPLS UNI without any extensions.  

   However, in some deployments of the GMPLS UNI, it is not practical 
   for the EN and its attached CN to share the same address space. This 
   can arise if the core and overlay networks were designed and deployed 
   separately or belong to different carriers. For example, the core 
   network may use IPv6 addresses, while the overlay network uses IPv4 
   addresses. Or, since the core network is a closed system, the 
   assignment of the IP addresses of the CNs may be independent of other 
   IP addresses outside the core network. This implies that the nodes in 
   the core network may use addresses which could collide with the edge 
   nodes in the overlay network. 

   [RFC4208] does not state how to ensure that an edge-node and its 
   attached core-node share the same address space. This document 
   analyzes the addressing deployment scenarios as follows: 

   1. Overlay network and core network share a common addressing policy. 
      This might be quite feasible in a multi-layer network operated by 
      a single carrier. 

      In this scenario, end-to-end UNI connectivity may use a single 
      RSVP session, and the core routing information (assuming it is 
      shared and not stripped for confidentiality reasons) will be 
      meaningful to the ENs. Note, however, that the overlay model 
      examined by this document assumes that there is some separation 
      between the overlay and core networks, and this might mean that 
      the overlay network is not able to see the topology or routing 
      information of the core network even when they share a common 
      address space. 

   2. ENs have visibility into the core network, but overlay and core 
      networks have different address spaces. This is the more common 
      model envisaged by [RFC4208] and for basic mode L1VPN deployments 
      [RFC5251]. The previous scenario can be seen to be a special case 
      of this scenario where the two address spaces are complementary. 
      In this deployment the ENs each have two addresses: one in the 
      overlay network and one in the core network. The source EN is 
 
 
Zhang                   Expires August 2013                  [Page 5] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

      aware of the addresses for itself, the ingress CN, the egress CN, 
      and the destination EN in the address space of the core network. 
      It may also have full visibility into the core network, but this 
      is not a requirement.  

      In this scenario, the ENs are responsible for performing address 
      mapping between the overlay network's addresses for the ENs, and 
      the core network's addresses for the same nodes and/or its TE 
      links. A typical deployment may assign addresses in the core 
      network address space for the EN and/or its TE links at the EN 
      side, so that EN can use these addresses to communicate with the 
      core network for UNI connection provisioning.  

      In this deployment, a single end-to-end RSVP-TE session can still 
      be utilized from the source EN to the destination EN using 
      addressing and naming from the core network's address space. 

   3. ENs do not have any knowledge of the core address space, or do not 
      support the address space the core network uses (e.g., ENs do not 
      support IPv6 that is used by the core network). ENs will have no 
      visibility into the core network.  

      In this scenario, the ingress CN is responsible for mapping 
      addresses to the core address space and filling in any additional 
      routing information. A typical deployment is to assign addresses 
      in the overlay address space for the ingress CN and/or its TE 
      links at the CN side, so that the EN can use overlay addresses to 
      reach the ingress CN and to identify the destination EN. 

      In this deployment the end-to-end connectivity must be created 
      either using "session stitching" (see Section 5.2) or "session 
      shuffling" (see Section 5.3). 

    

3. UNI Auto Discovery 

   When the end-to-end connection is set up across the core network, it 
   must be targeted at the destination CN so that it can be extended to 
   the destination EN. This means that either the source EN must know 
   the identity of the destination CN to which the destination EN is 
   attached, or the source CN must know this information. This requires 
   some form of "discovery" (possibly including configuration), and 
   depending on the addressing scheme in use (see Section 2), address 
   mapping needs to be performed by the source EN or the source CN. 

 
 
Zhang                   Expires August 2013                  [Page 6] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

   The discovery problem may be exacerbated when a variety of services 
   are requested since the source EN will need to know the capabilities 
   and available resources on the link between the destination CN and 
   the destination EN. It could discover this by attempting to set up a 
   connection and by drawing conclusions from connection setup failures, 
   but this is not efficient. Furthermore, in the case of a dual-homed 
   destination EN (such as EN2 in Figure 1), a choice of destination CN 
   must be made, and that choice may be influenced by the capabilities 
   and available resources on the CN-EN links leading to the destination 
   EN. 

   If the UNI is applied in an L1VPN scenario, two mechanisms for auto 
   discovery have been defined. Auto discovery of UNI using OSPFv2 is 
   provided in [RFC5252] using an L1VPN LSA to advertise the L1VPN 
   information via the L1VPN info TLV and the TE information of the CE-
   PE link (in the language of UNI, it's the EN-CN link) via the TE link 
   TLV. Auto discovery of UNI using BGP is provided in [RFC5195] by 
   having each edge CN advertise to other edge CN the following 
   information, at a minimum: its own IP address and the list of 
   <private address, provider address> tuples local to that PE.  Once 
   that information is received, the remote PEs will identify the list 
   of VPN members they have in common with the advertising PE, and use 
   the information carried within the discovery mechanism to perform 
   address resolution during the signaling phase of Layer-1 VPN 
   connections. 

    

4. UNI Path Computation 

   End-to-end UNI path computation includes three parts: the selection 
   of the source UNI link, the path computation inside the core network 
   and the selection of the destination UNI link. 

   The selection of UNI links may not be necessary in all scenarios. One 
   example is in the case of single-homing with only one UNI link 
   between EN and CN. Another example is manual selection of the UNI 
   link when the service is requested (i.e., as a function of the 
   service request such as the port mapping used in a L1VPN). In such 
   cases, the CN to which the source EN is attached, or the path 
   Computation Element (PCE) ([RFC4655]) which is responsible for the 
   core network, can perform the path computation across the core 
   network when the UNI signaling request is sent from the source EN to 
   the source CN.  

 
 
Zhang                   Expires August 2013                  [Page 7] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

4.1. UNI Link Selection 

   This document is specific to the overlay architectural model, and 
   that means that the source EN does not have the topology and TE 
   information of the core network. Therefore, in the case of multi-
   homing (i.e., the source EN is connected to more than one CN), the 
   source EN does not have enough information to make a correct choice 
   among all the UNI links between itself and the core network for an 
   optimal end-to-end connection. 

   In this case, a PCE whose computation domain covers both the core 
   network and the ENs attached to it can be used. Note that the GMPLS 
   UNI predates PCE and hence a PCE was not available in early GMPLS UNI 
   deployments. A PCE that has the topology and TE information of the 
   core network can use the UNI discovery mechanism described in Section 
   3 to learn the EN-CN relationship and the TE information of the UNI 
   links, and therefore has the ability to select the optimal UNI link 
   for the connection.  

   Figure 2 shows the procedures for UNI path computation using a single 
   PCE with visibility into the core network and information about all 
   of the CN-EN links. When the UNI path computation request is received, 
   the PCE can help the source EN to compute the end-to-end route of the 
   UNI connection based on routing information it has accesses to, so 
   that the source EN can create the UNI connection using the optimal 
   UNI link. As shown in Figure 2, the following steps are carried out: 

   Step 1: EN1 requests a path from EN1 to EN2 by sending a PCReg 
   message to the PCE;  

   Step 2: The PCE computes a path based on its view of the core network 
   and knowledge of all the EN-CN links. In this case, it returns the 
   path En1-CN4-CN5-Cn6-EN2 to the EN1 node; 

   Step 3: EN1 starts the signaling process to set up the LSP by using s 
   standard RSVP signaling process, using the path information as 
   computed.  

   If confidentiality of the topology within the core network needs to 
   be preserved, the Path Key Subobject (PKS) can be used for either 
   approach outlined here (see [RFC5520] and [RFC5553]). In the PCRep 
   message returned to EN1, the Confidential Path Segment (CPS) (i.e., 
   CN4-CN5-CN6) is encoded as a PKS by the PCE. Therefore, EN1 only 
   learns the selected UNI link from the PCE. When CN4 receives the UNI 
   signaling message from EN1 carrying the PKS, CN4 asks the PCE to 
   decode the PKS and then continues to signal the LSP. 

 
 
Zhang                   Expires August 2013                  [Page 8] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

          1) PCReq: EN1-EN2   +-----+ 
    +------------------------>|     | 
    |                         | PCE | 
    |  +----------------------|     | 
    |  |                      +-----+ 
    |  |  2) PCRep: EN1-CN4-CN5-CN6-EN2 
    |  | 
    |  |        +----------------------------------+ 
    |  |        |          Core Network            | 
    |  |        |  +----+      +----+      +----+  | 
    |  V   +----+--+ CN1+------+ CN2+------+ CN3+--+----+ 
   +----+  |    |  +--+-+      +--+-+      +--+-+  |    |  +----+ 
   |    +--+    |     |           |           |    |    +--+    | 
   | EN1| UNI   |     |           |           |    |   UNI | EN2| 
   |    +--+    |     |           |           |    |    +--+    | 
   +----+  |    |  +--+-+      +--+-+      +--+-+  |    |  +----+ 
           +----+--+ CN4+------+ CN5+------+ CN6+--+----+ 
     ---------> |  +----+      +----+      +----+  | 
   3) Signaling +----------------------------------+ 

         Figure 2 - Procedure using a PCE for UNI path computation 

              
   Note that in both cases described in this section, the PCE needs to 
   be visible to the ENs, and there also needs to be a control channel 
   between the PCE and the ENs for the exchange of PCE Protocol (PCEP) 
   messages. An alternative implementation could be that a PCE is 
   located inside each CN to which the source EN is attached, so that 
   the source EN can use the UNI control channel to send and receive the 
   PCEP messages. 

    

5. UNI Path Provisioning 

   The basic GMPLS UNI application is to provide end-to-end connections 
   between edge-nodes through a core network via the overlay model. This 
   section briefly describes four ways in which the end-to-end LSP can 
   be created and operated across the core network. 

5.1. Flat Model 

   In this model, the edge-nodes have the same switching capability as 
   the nodes in the core network. In this case, one single end-to-end 
   RSVP session through the edge-nodes and a series of core-nodes can be 
   used to create the connection, which forms a flat LSP model, as shown 
   in Figure 3. 
 
 
Zhang                   Expires August 2013                  [Page 9] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

                +----------------------------------+ 
                |          Core Network            | 
   +----+  UNI  |  +----+      +----+      +----+  |  UNI  +----+ 
   | EN +-------+--+ CN +------+ CN +------+ CN +--+-------+ EN | 
   +----+       |  +----+      +----+      +----+  |       +----+ 
      |         |                                  |         | 
      |         +----------------------------------+         | 
      |                                                      | 
      |<------------- End-to-end RSVP Session -------------->| 
      |                                                      | 
                         Figure 3 - The Flat Model 

   If the edge-nodes and their attached core-nodes share the same 
   address space, or the ENs can perform address mapping into the core 
   network address space, the GMPLS signaling described in [RFC3471], 
   [RFC3473] and other related specifications, with special ERO and RRO 
   processing as described in [RFC4208], can be used to create a 
   connection. 

5.2. Stitching Model 

   The stitching mechanism described in [RFC5150] can be used to create 
   an LSP segment (S-LSP) between the ingress and the egress CN, and to 
   stitch the end-to-end UNI connection to the created S-LSP, as shown 
   in Figure 4. 

                +----------------------------------+ 
                |          Core Network            | 
   +----+  UNI  |  +----+      +----+      +----+  |  UNI  +----+ 
   | EN +-------+--+ CN +------+ CN +------+ CN +--+-------+ EN | 
   +----+       |  +----+      +----+      +----+  |       +----+ 
      |         |    |                        |    |         | 
      |         +----+------------------------+----+         | 
      |              |                        |              | 
      |              |<-LSP Segment (S-LSP)-->|              | 
      |                                                      | 
      |<------------- End-to-end RSVP Session -------------->| 

                      Figure 4 - The Stitching Model 

   This model allows the core network a degree of independence so that 
   the S-LSP can be set up and modified without the knowledge of the 
   overlay network. Remember that stitching is a data plane function, so 
   that the EN-CN LSP segments are cross-connected to the S-LSP at the 
   edge CNs. This means that, just as in Section 5.1, the overlay and 
   core networks must have the same switching capabilities. However, the 
   control plane for the stitching model operates just as the 
 
 
Zhang                   Expires August 2013                 [Page 10] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

   hierarchical model described in Section 5.4, so the S-LSP appears as 
   a single hop in the overlay network.  

5.3. Session Shuffling Model 

   The session shuffling approach ([RFC5251]) is a modification of the 
   flat model described in Section 5.1. In this approach a single end-
   to-end session is established, but as the signaling messages pass 
   through the ingress and egress CNs, address mapping is performed on 
   all addresses carried by the messages to replace the addresses with 
   values from the correct address space. The ERO and RRO are stripped 
   from the messages as previously discussed, so there is no need for 
   the CNs to examine those objects to map addresses. However, all other 
   addresses must be mapped including the important session identifiers 
   (the source and destination addresses). Viewed from the outside 
   (perhaps through an NMS) this gives the impression of session 
   stitching because the session has different identifiers as it crosses 
   the core network. An NMS might, therefore, present the shuffling 
   model as the stitching model, or it might operate the same address 
   shuffling/mapping as is used by CNs.  

5.4. Hierarchal Model 

   If the ENs and CNs have the same switching capability, a tunnel 
   between the ingress and egress core-nodes can be provisioned to carry 
   the end-to-end connection. The tunnel may have a larger capacity than 
   the end-to-end UNI connection, depending on the policies configured 
   at the ingress CN of the core network. The end-to-end connection can 
   be nested into a tunnel, which forms the LSP hierarchy [RFC4206] as 
   shown in Figure 5. If the tunnel has a larger capacity, other LSPs 
   can also be nested within the same tunnel. 

   Alternatively, if the ENs and CNs have different switching 
   capabilities the LSP hierarchical model can also be used exactly as 
   described in [RFC4206]. 

   In the hierarchal model, the end-to-end connection can be divided 
   into three hops: one for each UNI link and one hop across the core 
   network. The core network tunnel can be pre-provisioned via network 
   planning, or triggered by the UNI signalling. For the latter case, 
   [RFC5212], [RFC6001] and other multi-layer network related 
   specifications can be used to create the hierarchical LSP. 

    

    

 
 
Zhang                   Expires August 2013                 [Page 11] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

                +----------------------------------+ 
                |          Core Network            | 
   +----+  UNI  |  +----+      +----+      +----+  |  UNI  +----+ 
   | EN +-------+--+ CN +======+ CN +======+ CN +--+-------+ EN | 
   +----+       |  +----+      +----+      +----+  |       +----+ 
      |         |    |                        |    |         | 
      |         +----+------------------------+----+         | 
      |              |                        |              | 
      |              |<-Core Network Tunnel-->|              | 
      |                                                      | 
      |<------------- End-to-end RSVP Session -------------->| 
      |                                                      | 

                      Figure 5 - The Hierarchal Model 

    

6. UNI Recovery 

   One of the significant uses of GMPLS is to provide recovery 
   mechanisms for connections. Recovery and protection mechanisms are 
   also needed in many UNI scenarios, and the relationship between the 
   overlay and core network provide obvious places at which to operate 
   the recovery techniques.  

6.1. End-to-end Recovery 

   In the case of multi-homing, UNI end-to-end recovery is possible. As 
   shown in Figure 6, the working path (W) and the protection path (P) 
   are disjoint from each other not only inside the core network, but 
   also at both the source and destination sides of the UNI. Mechanisms 
   need to be provided to ensure the selection of disjoint working and 
   backup paths as discussed in the following subsections. 

   It should be noted that end-to-end recovery can be operated even when 
   the ENs are single-homed. However, obviously, in this case there is 
   no protection against the failure of an EN-CN link, or of the edge CN 
   itself. 

    

                +----------------------------------+ 
                |          Core Network            | 
             W  |  +----+      +----+      +----+  |   
           +----+--+ CN +------+ CN +------+ CN +--+----+ 
   +----+  |    |  +----+      +----+      +----+  |    |  +----+ 
   |    +--+    |                                  |    +--+    | 
 
 
Zhang                   Expires August 2013                 [Page 12] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

   | EN | UNI   |                                  |   UNI | EN | 
   |    +--+    |                                  |    +--+    | 
   +----+  |    |  +----+      +----+      +----+  |    |  +----+ 
           +----+--+ CN +------+ CN +------+ CN +--+----+ 
             P  |  +----+      +----+      +----+  | 
                +----------------------------------+ 

                    Figure 6 - UNI End-to-End Recovery 

6.1.1. Serial Provisioning of Working and Protection Paths 

   In serial provisioning, one path is computed before another and the 
   associated LSP may even be set up before the second path is computed. 
   In the case where the working path is computed and created before the 
   protection path, path computation for the protection path needs to 
   select a (maximally) disjoint path given this existing working path. 

   If the EN is allowed to see details of the core network, the EN can 
   use the RRO to collect the route of the working path. It can then use 
   the Exclude Route Object (XRO) to exclude the working path when 
   signaling the protection path, as described in [RFC4874]. 

   But in most cases, in order to preserve the confidentiality of 
   topology within the core network, the route of the working path as it 
   traverses the core network will be hidden from the EN. In such cases, 
   the RRO and XRO mechanism cannot be used. An alternative would be to 
   only collect the Shared Risk Group (SRG) information, but not the 
   full path information. This is because the SRG information is 
   normally less confidential than the information of node ID and link 
   ID.  Another possible solution is encrypted the SRG information and 
   provide it to the EN nodes, so that the EN nodes can using this 
   information to convey the diversity constraint, as the method 
   specified in [UNIExt].In an application scenario where a PCE is 
   involved inside the core network, then the Path Key mechanism can be 
   used. The confidential path segment, i.e., the route of the working 
   path as it traverses the core network, is encoded as a PKS by the PCE 
   when computing the working path [RFC5520]. This PKS can be used by 
   the EN when it requests the PCE to compute a protection path, to 
   exclude the nodes and links used by the working path. As previously 
   described, the PKS is also used in signaling [RFC5553] so that the EN 
   can indicate to the CN what path to use across the core network. 

   In order to specify the diversity requirement, it is required that 
   the PKS should be carried in the XRO in both PCEP message and RSVP-TE 
   signaling. 

 
 
Zhang                   Expires August 2013                 [Page 13] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

6.1.2. Concurrent Computation of Working and Protection Path 

   The working and protection path can be computed at the same time 
   (e.g., by PCE or by one of the CNs to which the source EN is 
   attached).  

   [PCE-GMPLS] adds support for an end node to request a protected 
   service using the protection types defined in [RFC4872].Therefore, 
   it's possible that the source EN requests the edge CN or PCE to 
   compute both the working and the protection path at the same time. At 
   this time, the disjunction requirement can be resolved inside the 
   path computation server. 

   Same as described in the previous section, the path segment 
   traversing the core network can be encoded as a PKS if 
   confidentiality is requested. 

    

6.2. Segment Recovery 

   The UNI connection may request protection only inside the core 
   network, especially in case of single-homing. A UNI segment 
   protection example is shown in Figure 7. In this case, the core 
   network provides a "recovery domain". 

              +--------------------------------------+ 
              |            Core Network              | 
              |         W  +----+  +----+            | 
              |         +--+ CN +--+ CN +--+         | 
   +----+     | +----+  |  +----+  +----+  |  +----+ |     +----+ 
   |    |     | |    +--+                  +--+    | |     |    | 
   | EN +-----+-+ CN |                        | CN +-+-----+ EN | 
   |    | UNI | |    +--+                  +--+    | | UNI |    | 
   +----+     | +----+  |  +----+  +----+  |  +----+ |     +----+ 
              |         +--+ CN +--+ CN +--+         | 
              |         P  +----+  +----+            | 
              +--------------------------------------+ 

                      Figure 7 - UNI Segment Recovery 

   [RFC4873] provides a mechanism for segment recovery, in which the 
   PROTECTION Object is extended to indicate segment recovery, and the 
   Secondary ERO (SERO) is introduced for the explicit control of the 
   protection LSP between the branch node and the merge node. 

 
 
Zhang                   Expires August 2013                 [Page 14] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

   However, in the overlay model, the mechanisms of segment recovery 
   described in [RFC4873] may not be appropriate. In particular, the 
   source EN might not know the CN to which the destination EN is 
   attached. That means that the source EN knows the branch for the 
   protection segment, but does not know the merge node.  

   But the model shown in Figure 7 is particularly important because it 
   places the responsibility for service delivery with the edge CNs. 
   This will be a common operational model in overlay networks. 
   Fortunately the stitching model (Section 5.2) and the hierarchical 
   model (Section 5.4) are good at providing the necessary protection 
   within the core network without the ENs having to be aware of the 
   paths in the core network. 

    

7. UNI Call 

   The Call is a fundamental component of the ASON model [G.8080]. It is 
   used to maintain the association between one or more user 
   applications and the network, and to control the set-up, release, 
   modification, and maintenance of sets of Connections (LSPs). In 
   simple cases, the Call and Connection can be established at the same 
   time and in a strict one-to-one ratio. In this case, Call signaling 
   requires only minor extensions to connection signaling. However, if 
   Calls are handled separately from Connections, or if more than one 
   Connection can be associated with a single Call, additional Call 
   signaling is required. 

   The GMPLS Call, defined in [RFC4974], provides a mechanism to 
   negotiate agreement between endpoints possibly in cooperation with 
   the nodes that provide access to the network. Typically the GMPLS 
   Call can be applied in the UNI scenario for access link capability 
   exchange, policy, authorization, security, and so on. 

7.1. Exchange of UNI Link Information 

   It is possible that the TE attributes of the access link (i.e., the 
   UNI link) are not shared across the core network. So the source EN 
   may not have the TE information of the destination access link as 
   well as the capability of the destination EN. For example, in case of 
   TDM network, the Virtual Concatenation (VCAT) and Link Capacity 
   Adjustment Scheme (LCAS) capability of the destination EN may not be 
   known.  

   In this case, the source EN can raise a Call carrying the 
   LINK_CAPABILITY object to have a capability exchange with the 
 
 
Zhang                   Expires August 2013                 [Page 15] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

   destination EN, as described in [RFC4974]. 

7.2. Control of Call Route 

   When applying the Call, it's possible that there are multiple core 
   network domains between the source EN (Call initiator) and the 
   destination EN (Call terminator), or there is more than one Call 
   manager in the core network (e.g., in the multi-homing scenario where 
   the CNs to which the ENs are attached act as the Call managers). 

   In the both cases, when establishing the Call, there may be multiple 
   alternative routes for the Call message to reach the destination EN. 
   One can simply use the hop-by-hop manner (i.e., each Call manager 
   determines the next Call manager to which the Call message will be 
   sent by itself) to control the path of the Call. 

   However, in the practical deployment of UNI Call, commercial and 
   policy motivations normally play an important role in selecting the 
   Call route, especially in the multi-domain scenario. In this case, 
   the hop-by-hop manner is not practical because the route of the Call 
   needs to be pre-determined in consideration of commercial and policy 
   factors before establishing the Call. 

   Therefore, it is desirable to allow full control of the Call by the 
   source EN. That is, the source EN can identify the full Call route 
   and signal it explicitly, so that the Call message can be forwarded 
   along the desired route. Moreover, the management plane needs to be 
   able to identify the Call route explicitly as an instruction to the 
   source EN. 

    

8. UNI Multicast 

   Data plane multicasting is supported in existing Traffic-Engineering 
   networks. GMPLS provides extensions to RSVP-TE to support 
   provisioning of point-to-multipoint (P2MP) TE LSPs via the control 
   plane, as described in [RFC4461] and [RFC4875].  

   In the scenarios where P2MP is supported using the overlay 
   architectural model, it is a requirement to transport signals from 
   one source EN to multiple destination ENs. One could create a point-
   to-point (P2P) connection between the source EN and each destination 
   EN, but it will likely be a waste of bandwidth resource both of the 
   UNI link and in the core network.  

 
 
Zhang                   Expires August 2013                 [Page 16] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

   Therefore, there are some scenarios required to support point-to-
   multipoint (P2MP) TE LSPs from one source EN to multiple leaf ENs. 

8.1. UNI Multicast Connection Model 

   There are two cases for the UNI multicast. For the first case, only 
   the ingress and egress CNs in the core network support P2MP. The core 
   network has to provide multiple P2P connections between ingress CN 
   and each egress CN for the end-to-end UNI multicast, as shown in 
   Figure 8. This relieves the pressure on the source UNI link, but does 
   not help the over use of the core links such as CN1-CN2. 

    
            +----------------------------------------+ 
            |              Core Network              | 
            |  +-----+        +-----+       +-----+  |UNI +---+ 
   +---+ UNI|  |     +--------+-----+-------+     +--+----+EN2| 
   |EN1+----+--+ CN1 +--------+-\CN2|       | CN3 |  |    +---+ 
   +---+    |  |     +--------+\ \  |       |     |  |    Leaf A 
   Source   |  +-----+        +-+-+-+       +-----+  | 
            |                   | |                  | 
            |                 +-+-+-+       +-----+  |UNI +---+ 
            |                 | |  \+-------+     +--+----+EN3| 
            |                 | |CN4|       | CN5 |  |    +---+ 
            |                 +-+---+       +-----+  |    Leaf B 
            |                   |                    | 
            |                 +-+---+       +-----+  |UNI +---+ 
            |                 | \---+-------+     +--+----+EN4| 
            |                 | CN6 |       | CN7 |  |    +---+ 
            |                 +-----+       +-----+  |    Leaf C 
            +----------------------------------------+ 

            Figure 8 - Only ingress/egress CNs support multicast 

    

   For example, in multi-layer scenario of a packet overlay network with 
   a TDM core, the ingress/egress CNs may have packet multicast 
   capabilities and therefore can adapt the packets from EN into 
   multiple TDM connections to transit the core network, but the CNs 
   inside the core network only support point-to-point (P2P) TDM 
   connections.  

   In another case, all the CNs in the core network can support 
   multicast, so that the core network can create a P2MP LSP to provide 
   the end-to-end UNI multicast, as shown in Figure 9.  

 
 
Zhang                   Expires August 2013                 [Page 17] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

            +----------------------------------------+ 
            |              Core Network              | 
            |  +-----+        +-----+       +-----+  |UNI +---+ 
   +---+ UNI|  |     +--------+-+-->+-------+     +--+----+EN2| 
   |EN1+----+--+ CN1 |        | |CN2|       | CN3 |  |    +---+ 
   +---+    |  +-----+        +-V---+       +-----+  |    Leaf A 
   Source   |                   |                    | 
            |                 +-+---+       +-----+  |UNI +---+ 
            |                 | +-->+-------+     +--+----+EN3| 
            |                 | |CN4|       | CN5 |  |    +---+ 
            |                 +-V---+       +-----+  |    Leaf B 
            |                   |                    | 
            |                 +-+---+       +-----+  |UNI +---+ 
            |                 | \-->+-------+     +--+----+EN4| 
            |                 | CN6 |       | CN7 |  |    +---+ 
            |                 +-----+       +-----+  |    Leaf C 
            +----------------------------------------+ 

                   Figure 9 - All CNs support multicast 

   For example, in the Ethernet over OTN scenario, if the core network 
   can support ODU0 multicast, then an ODU0 P2MP LSP can be created 
   inside the core network to carry the client Gigabit Ethernet (GE) 
   signal for the ENs.  

   Note that the branching of the P2MP connection could also happen at 
   the source EN if the EN is multi-homed. In this case, each branch 
   from the source EN uses a separate UNI link connecting the source EN 
   to the core network. For each UNI branch, the connection model inside 
   the core network is the same as described in this section. 

8.2. UNI Multicast Connection Provisioning 

   The four UNI connection provisioning models, as described in Section 
   5, should also be applied in the UNI multicast scenario. 

   For the flat model, one end-to-end P2MP session as described in 
   [RFC4875] can be used to create the P2MP LSP from source EN to leaf 
   ENs. 

   For the stitching model, multiple P2P LSP segments or one P2MP LSP 
   segment between the ingress CN and each egress CNs needs to be 
   created and then stitched to the UNI P2MP LSP. GMPLS UNI signaling 
   should have the capability to convey the multicast information by 
   using stitching model. 

 
 
Zhang                   Expires August 2013                 [Page 18] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

   For the session shuffling model, one end-to-end P2MP session can be 
   used to create the P2MP LSP, with an address mapping performed at 
   both ingress and egress CNs. 

   For the hierarchical model, multiple P2P LSP tunnels or one P2MP LSP 
   tunnel between the ingress CN and each egress CNs needs be triggered 
   by the UNI signaling for creating the P2MP LSP. GMPLS UNI signaling 
   should have the capability to convey the multicast information by 
   using the hierarchical model.  

    

9. Security Considerations 

   [RFC5920] provides an overview of security vulnerabilities and 
   protection mechanisms for the GMPLS control plane, which is 
   applicable to this document. 

   The details of the specific security measures of the overlay network 
   architectural model are provided in [RFC4208], which permits the core 
   network to filter out specific RSVP objects to hide its topology from 
   the EN.  

   Furthermore, if PCE is used, the security issues described in 
   [RFC4655] should also be considered. 

   Additionally, when the PKS mechanism is applied, the security issues 
   can be dealt with using [RFC5520] and [RFC5553]. 

    

10. IANA Considerations 

   This informational document does not make any requests for IANA 
   action. 

    

11. Acknowledgments 

   TBD. 

 
 
Zhang                   Expires August 2013                 [Page 19] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

12. References 

12.1. Normative References 

    [RFC3209]  D. Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 
               Tunnels", RFC3209, December 2001. 

   [RFC3471]   Berger, L., Ed., "Generalized Multi-Protocol Label 
               Switching (GMPLS) Signaling Functional Description", RFC 
               3471, January 2003. 

   [RFC3473]   L. Berger, Ed., "Generalized Multi-Protocol Label 
               Switching (GMPLS) Signaling Resource ReserVation 
               Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 
               3473, January 2003. 

   [RFC3945]   Mannie, E., "Generalized Multi-Protocol Label Switching 
               (GMPLS) Architecture", RFC 3945, October 2004. 

   [RFC4203]   Kompella, K., and Rekhter, Y., "OSPF Extensions in 
               Support of Generalized Multi-Protocol Label Switching 
               (GMPLS)", RFC 4203, October 2005. 

   [RFC4206]   K. Kompella et al, "Label Switched Paths (LSP) Hierarchy 
               with Generalized Multi-Protocol Label Switching (GMPLS) 
               Traffic Engineering (TE)", RFC4206, October 2005. 

   [RFC4208]   G. Swallow et al, "Generalized Multiprotocol Label 
               Switching (GMPLS) User-Network Interface (UNI): Resource 
               ReserVation Protocol-Traffic Engineering (RSVP-TE) 
               Support for the Overlay Model", RFC4208, October 2005. 

   [RFC4655]   A. Farrel et al, "A Path Computation Element (PCE)-Based 
               Architecture", RFC4655, August 2006. 

   [RFC4847]   T. Takeda, Ed., "Framework and Requirements for Layer 1 
               Virtual Private Networks", RFC4847, April 2007. 

   [RFC4872]   J.P. Lang et al, "RSVP-TE Extensions in Support of End-
               to-End Generalized Multi-Protocol Label Switching (GMPLS) 
               Recovery", RFC4872, May 2007. 

   [RFC4873]   L. Berger et al, "GMPLS Segment Recovery", RFC4873, May 
               2007. 

 
 
Zhang                   Expires August 2013                 [Page 20] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

   [RFC4874]   CY. Lee et al, "Exclude Routes - Extension to Resource 
               ReserVation Protocol-Traffic Engineering (RSVP-TE)", 
               RFC4874, April 2007. 

   [RFC4875]   R. Aggarwal et al, "Extensions to Resource Reservation 
               Protocol - Traffic Engineering (RSVP-TE) for Point-to-
               Multipoint TE Label Switched Paths (LSPs)", RFC4875, May 
               2007. 

   [RFC4974]   D. Papadimitriou and A. Farrel, Ed., "Generalized MPLS 
               (GMPLS) RSVP-TE Signaling Extensions in Support of Calls", 
               RFC4974, August 2007. 

   [RFC5150]   A. Ayyangar et al, "Label Switched Path Stitching with 
               Generalized Multiprotocol Label Switching Traffic 
               Engineering (GMPLS TE)", RFC5150, February 2008. 

   [RFC5195]   Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based 
               Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008. 

   [RFC5251]   D. Fedyk and Y. Rekhter, Ed., "Layer 1 VPN Basic Mode", 
               RFC5251, July 2008. 

   [RFC5252]   I. Bryskin and L. Berger Ed., "OSPF-Based Layer 1 VPN 
               Auto-Discovery", RFC5252, July 2008. 

   [RFC5520]   R. Bradford, Ed., "Preserving Topology Confidentiality in 
               Inter-Domain Path Computation Using a Path-Key-Based 
               Mechanism", RFC5520, April 2009. 

   [RFC5553]   A. Farrel, Ed., "Resource Reservation Protocol (RSVP) 
               Extensions for Path Key Support", RFC5553, May 2009. 

   [RFC6001]   Dimitri Papadimitriou et al, "Generalized Multi-Protocol 
               Label Switching (GMPLS) Protocol Extensions for Multi-
               Layer and Multi-Region Networks (MLN/MRN)", RFC6001, 
               October, 2010. 

   [RFC6107]   K. Shiomoto, A. Farrel, "Procedures for Dynamically 
               Signaled Hierarchical Label Switched Paths", RFC6107, 
               February 2011. 

   [G.8080]    ITU-T Rec. G.8080/Y.1304, "Architecture for the 
               Automatically Switched Optical Network (ASON)," June 2006 
               (and Amend.2, September 2010). 

     
 
 
Zhang                   Expires August 2013                 [Page 21] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

12.2. Informative References 

   [RFC4461]   S. Yasukawa, Ed., "Signaling Requirements for Point-to-
               Multipoint Traffic-Engineered MPLS Label Switched Paths 
               (LSPs)", RFC4461, April 2006. 

   [RFC5212]   K. Shiomoto et al, "Requirements for GMPLS-Based Multi-
               Region and Multi-Layer Networks (MRN/MLN)", RFC5212, July 
               2008. 

   [RFC5253]   T. Takeda, Ed., "Applicability Statement for Layer 1 
               Virtual Private Network (L1VPN) Basic Mode", RFC 5253, 
               July 2008. 

   [RFC5339]   JL. Le Roux et al, "Evaluation of Existing GMPLS 
               Protocols against Multi-Layer and Multi-Region Networks 
               (MLN/MRN)", RFC5339, September 2008. 

   [RFC5441]   JP. Vasseur et al, "A Backward-Recursive PCE-Based 
               Computation (BRPC) Procedure to Compute Shortest 
               Constrained Inter-Domain Traffic Engineering Label 
               Switched Paths", RFC5441, April 2009. 

   [RFC5623]   Oki, E., Takeda, T., Le Roux, J.L., and Farrel, A., 
               "Framework for PCE-Based Inter-Layer MPLS and GMPLS 
               Traffic Engineering", RFC 5623, September 2009. 

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

   [Call-ext]  Fatai Zhang et al, "RSVP-TE extensions to GMPLS Calls", 
               draft-zhang-ccamp-gmpls-call-extensions-01.txt, July 08, 
               2009. 

   [PCE-GMPLS] C. Margaria et al, "PCEP extensions for GMPLS", draft-
               ietf-pce-gmpls-pcep-extensions-07.txt, October 21, 2012. 

   [SRLG-FA]   Fatai Zhang et al, "RSVP-TE Extensions for Configuration 
               SRLG of an FA", draft-ietf-ccamp-rsvp-te-srlg-collect-
               01.txt, October 22, 2012. 

   [RFC6344]   G. Bernstein et al, "Operating Virtual Concatenation 
               (VCAT) and the Link Capacity Adjustment Scheme (LCAS) 
               with Generalized Multi-Protocol Label Switching (GMPLS)", 
               RFC6344, August 2011. 

 
 
Zhang                   Expires August 2013                 [Page 22] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

   [UNIExt]    D. Fedyk, D. Beller, Lieven Levrau, D. Ceccarelli, F. Zhang, 
               et al, "UNI Extensions for Diversity and Latency Support", 
               draft-fedyk-ccamp-uni-extensions-00.txt, Feb. 2013;  

    

13. Contributors' Address 

   Yi Lin 
   Huawei Technologies 
   F3-5-B R&D Center, Huawei Base 
   Bantian, Longgang District 
   Shenzhen 518129 P.R.China 
    
   Phone: +86-755-28972914 
   Email: yi.lin@huawei.com
    
    
   Young Lee 
   Huawei Technologies 
   1700 Alma Drive, Suite 100 
   Plano, TX 75075 
   USA 
    
   Phone: (972) 509-5599 (x2240) 
   Email: leeyoung@huawei.com
    
    
   Dan Li 
   Huawei Technologies 
   F3-5-B R&D Center, Huawei Base 
   Bantian, Longgang District 
   Shenzhen 518129 P.R.China 
    
   Phone: +86-755-28973237 
   Email: huawei.danli@huawei.com
    

14. Authors' Addresses 

   Fatai Zhang 
   Huawei Technologies 
   F3-5-B R&D Center, Huawei Base 
   Bantian, Longgang District 
   Shenzhen 518129 P.R.China 
    
   Phone: +86-755-28972912 
 
 
Zhang                   Expires August 2013                 [Page 23] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

   Email: zhangfatai@huawei.com
    
    
   Oscar Gonzalez de Dios 
   Telefonica Investigacion y Desarrollo 
   Emilio Vargas 6 
   Madrid,   28045 
   Spain 
    
   Phone: +34 913374013 
   Email: ogondio@tid.es
    
    
   Adrian Farrel 
   Old Dog Consulting 
    
   EMail: adrian@olddog.co.uk
    
    
   Xian Zhang 
   Huawei Technologies 
   F3-5-B R&D Center, Huawei Base 
   Bantian, Longgang District 
   Shenzhen 518129 P.R.China 
    
   Phone: +86-755-28972913 
   Email: zhang.xian@huawei.com
    
    
   Daniele Ceccarelli 
   Ericsson 
   Via A. Negrone 1/A 
   Genova - Sestri Ponente 
   Italy 
    
   Email: daniele.ceccarelli@ericsson.com
    
    
    
Intellectual Property 
 
   The IETF Trust takes no position regarding the validity or scope of   
   any Intellectual Property Rights or other rights that might be   
   claimed to pertain to the implementation or use of the technology   
   described in any IETF Document or the extent to which any license   
   under such rights might or might not be available; nor does it   

 
 
Zhang                   Expires August 2013                 [Page 24] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

   represent that it has made any independent effort to identify any   
   such rights. 

   Copies of Intellectual Property disclosures made to the IETF   
   Secretariat and any assurances of licenses to be made available, or   
   the result of an attempt made to obtain a general license or   
   permission for the use of such proprietary rights by implementers or   
   users of this specification can be obtained from the IETF on-line IPR   
   repository at http://www.ietf.org/ipr 

   The IETF invites any interested party to bring to its attention any   
   copyrights, patents or patent applications, or other proprietary   
   rights that may cover technology that may be required to implement   
   any standard or specification contained in an IETF Document. Please   
   address the information to the IETF at ietf-ipr@ietf.org. 

   The definitive version of an IETF Document is that published by, or   
   under the auspices of, the IETF. Versions of IETF Documents that are   
   published by third parties, including those that are translated into   
   other languages, should not be considered to be definitive versions   
   of IETF Documents. The definitive version of these Legal Provisions   
   is that published by, or under the auspices of, the IETF. Versions of   
   these Legal Provisions that are published by third parties, including   
   those that are translated into other languages, should not be   
   considered to be definitive versions of these Legal Provisions. 

   For the avoidance of doubt, each Contributor to the IETF Standards   
   Process licenses each Contribution that he or she makes as part of   
   the IETF Standards Process to the IETF Trust pursuant to the   
   provisions of RFC 5378. No language to the contrary, or terms,   
   conditions or rights that differ from or are inconsistent with the   
   rights and licenses granted under RFC 5378, shall have any effect and   
   shall be null and void, whether published or posted by such   
   Contributor, or included with or in such Contribution. 

 
Disclaimer of Validity 
 
   All IETF Documents and the information contained therein are provided   
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE   
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE   
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL   
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY   
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE   
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS   
   FOR A PARTICULAR PURPOSE. 

 
 
Zhang                   Expires August 2013                 [Page 25] 


draft-zhang-ccamp-gmpls-uni-app-03.txt                    February 2013 

 
 
Copyright Notice 
 
   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. 

 
 
Zhang                   Expires August 2013                 [Page 26]