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

Versions: 00 01 02 03 04 05

Network Working Group                                        Fatai Zhang
Internet Draft                                                    Huawei
Category: Informational                              O. Gonzalez de Dios
                                   Telefonica Investigacion y Desarrollo
                                                           D. Ceccarelli
                                                            G. Bernstein
                                                       Grotto Networking
                                                               A. Farrel
                                                      Old Dog Consulting
Expires: September 14, 2011                               March 14, 2011

   Applicability of Generalized Multiprotocol Label Switching (GMPLS)
                      User-Network Interface (UNI)


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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 14, 2011.


   Generalized Multiprotocol Label Switching (GMPLS) defines a series of
   protocols for the creation of Label Switched Paths (LSPs) in various
   switching technologies. The GMPLS User-Network Interface (UNI) was

Zhang                  Expires September 2011                  [Page 1]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

   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 suggested simple extensions to existing technologies to
   further enable the UNI and points out some existing unresolved issues.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

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 ....................................... 7
   5. UNI Path Provisioning ......................................... 9
      5.1. Flat Model .............................................. 10
      5.2. Stitching Model ......................................... 10
      5.3. Session Shuffling Model ................................. 11
      5.4. Hierarchy Model ......................................... 11
   6. UNI Recovery ................................................. 12
      6.1. End-to-end Recovery ..................................... 12
         6.1.1. Serial Provisioning of Working & Protection Path ... 12
         6.1.2. Concurrent Computation of Working & Protection Path. 13
      6.2. Segment Recovery ........................................ 13
   7. UNI Call ..................................................... 14
      7.1. Exchange of UNI Link Information ........................ 15
      7.2. Control of Call Route ................................... 15
   8. UNI Multicast ................................................ 16
      8.1. UNI Multicast Connection Model .......................... 16
      8.2. UNI Multicast Connection Provisioning ................... 17
   9. Security Considerations ...................................... 18
   10. IANA Considerations ......................................... 18
   11. Acknowledgments ............................................. 19
   12. References .................................................. 19
      12.1. Normative References ................................... 19

Zhang                  Expires September 2011                  [Page 2]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

      12.2. Informative References ................................. 21
   13. Authors' Addresses .......................................... 22

1. Introduction

   Generalized Multiprotocol Label Switching (GMPLS) defines a series 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

              Figure 1 - Applying GMPLS overlay model at UNI

Zhang                  Expires September 2011                  [Page 3]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

   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 who initiates the connection
      (e.g., EN1);

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

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

   -  "egress CN" refers to the core-node to which the destination EN
      is attached (e.g., 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 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 received against its topology database
   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 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 was developed 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 existing unresolved issues.

Zhang                  Expires September 2011                  [Page 4]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

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 the practical deployment of GMPLS UNI, the requirement of
   sharing the same address space between EN and its attached CN may not
   be satisfied if the core network and the overlay network are designed
   and deployed separately, especially if the two networks 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 is independent of other IP addresses outside the
   core network. This implies that the nodes in the core network may use
   addresses which collide with the edge nodes in the overlay network.

   Thus, the addressing deployment for the GMPLS UNI can be divided into
   three scenarios:

   1. Overlay network and core network share a common addressing policy.
      As noted above, there are many situations where this may be
      impractical, but it 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]), and 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 source EN is 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

Zhang                  Expires September 2011                  [Page 5]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

      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.
      Additionally, the source EN must use core network addresses to
      identify the CNs. In this deployment, a single end-to-end RSVP-TE
      session can still be utilized from source EN to destination EN.

   3. ENs do not have any knowledge of the core address space and has no
      visibility into the core network. The source EN must still know an
      address for the ingress CN, but in this scenario, the EN uses an
      overlay address to reach the CN and to identify the destination EN.
      The ingress CN is responsible for mapping addresses to the core
      address space and for filling in any additional routing
      information. 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) will
   require address mapping to be performed by the source EN or the
   source CN.

   The discovery problem may be exacerbated when the a variety of
   services may be 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 the
   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 L1VPN scenario, the auto discovery of UNI
   using OSPFv2 is provided in [RFC5252]. A new L1VPN LSA is introduced
   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.

Zhang                  Expires September 2011                  [Page 6]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

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 necessary in some scenarios. One
   example is in case of single-homing with only one UNI link between EN
   and CN, and another example is manual selection of UNI link when the
   service is requested. 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.

4.1. UNI Link Selection

   This document is specific to the overlay architectural model to the
   source EN which 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

   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 to solve this
   problem in early GMPLS UNI deployments. The PCE 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 an example of UNI path computation using a single PCE
   with visibility into both networks. The PCE can help the source EN to
   compute the end-to-end connection when the UNI path computation
   request is received, so that the source EN can learn which UNI link
   to be selected.

Zhang                  Expires September 2011                  [Page 7]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

          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 - PCE for UNI path computation (1)

   Alternatively, the path can be computed by cooperating PCEs, as shown
   in Figure 3. The source EN does not experience any difference in
   behavior in that it sends its computation request to its local PCE,
   and receives a response telling it what path to use. However, the
   local PCE may not be aware of the topology of the core network and
   may need to contact a second PCE to supply the missing information.

Zhang                  Expires September 2011                  [Page 8]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

         +-----+                 +-----+
         |     |---------------->|     |
         | PCE1|     2) BRPC     | PCE2|
         |     |<----------------|     |
         +-----+                 +-----+
          ^  |
      1)  |  |3) PCRep: EN1-CN4-CN5-CN6-EN2
    PCReq:|  |        +------------------------------+
   EN1-EN2|  |        |         Core Network         |
          |  |        |  +----+    +----+    +----+  |
          |  V   +----+--+ CN1+----+ CN2+----+ CN3+--+----+
         +----+  |    |  +--+-+    +--+-+    +--+-+  |    |  +----+
         |    +--+    |     |         |         |    |    +--+    |
         | EN1| UNI   |     |         |         |    |   UNI | EN2|
         |    +--+    |     |         |         |    |    +--+    |
         +----+  |    |  +--+-+    +--+-+    +--+-+  |    |  +----+
                 +----+--+ CN4+----+ CN5+----+ CN6+--+----+
           ---------> |  +----+    +----+    +----+  |
         4) Signaling +------------------------------+

     (BRPC: Backward-Recursive PCE-Based Computation, see [RFC5441])

                Figure 3 - PCE for UNI path computation (2)

   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, the EN1 only
   learns the selected UNI link from PCE. When receiving the UNI
   signaling carrying the PKS from EN1, CN4 can request the PCE to
   decode the PKS and then continue to create the connection.

   Note that in both cases the PCE should be visible to the ENs and
   there should be control channel between PCE and EN for the
   transmission of PCEP messages. An alternative implementation could be
   that the 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.

Zhang                  Expires September 2011                  [Page 9]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

5.1. Flat Model

   The edge-nodes may have the same switching capability and switching
   capacity 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 4.

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

                           Figure 4 - Flat model

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

5.2. Stitching Model

   Alternatively, 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 5.

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

                        Figure 5 - Stitching model

Zhang                  Expires September 2011                 [Page 10]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

5.3. Session Shuffling Model

   The session shuffling approach ([RFC5251]) is a hybrid of the flat
   model and the stitching model described in the previous two sections.
   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 place the addresses into the correct address spaces. The ERO and
   RRO would normally be stripped (as previously discussed) but the
   important session identifiers (the source and destination addresses)
   are changed giving the impression that the session identifiers have
   been changed.

5.4. Hierarchy Model

   In case that the ENs and the CNs have the same switching capability,
   a tunnel between the ingress and egress core-nodes can be provisioned.
   The tunnel may have a larger capacity than the end-to-end UNI
   connection, which may depend on the policies configured at the
   ingress of the core network. The end-to-end connection can be nested
   into the tunnel, which forms the LSP hierarchy.

   Another case is that the edge-nodes have different switching
   capabilities with the core network. In such a case, the LSP hierarchy
   model should also be used.

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

                        Figure 6 - Hierarchy model

   In the hierarchy 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 signal. For the latter case, the [RFC5212],
   [RFC6001] and other multi-layer network related standards are
   possible to be used to create the hierarchical LSP.

Zhang                  Expires September 2011                 [Page 11]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

6. UNI Recovery

   One of the significant uses of GMPLS is to provide recovery
   mechanisms for connections, which is also needed in many UNI

6.1. End-to-end Recovery

   In the case of multi-homing, UNI end-to-end recovery is possible. As
   shown in Figure 7, 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.

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

                    Figure 7 - UNI end-to-end recovery

6.1.1. Serial Provisioning of Working & Protection Path

   In the case that the working path is computed and created before the
   protection path, path computation needs to compute a disjoint (or
   maximally disjoint) protection path given this existing working path.

   If the information concerning the working path segment traversing the
   core network is known by the EN without considering the
   confidentiality, then the EN can easily use the RRO to collect the
   working path information, and use the XRO to exclude the working path
   when creating the protection path, as described in [RFC4874].

   But in most cases, in order to preserve the confidentiality of
   topology within the core network, the information of path segment
   traversing the core network should be hidden from the EN. In such

Zhang                  Expires September 2011                 [Page 12]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

   case, the RRO & XRO mechanism in [RFC4874] 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.

   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 working path segment traversing the core
   network, is encoded as a PKS by the PCE when computing the working
   path. This PKS can be brought to the source EN, so when it request
   that the PCE compute a protection path, the PKS can be used to
   exclude the working path segment inside the core network.

   [RFC5520] provides a mechanism to hide the CPS using PKS in the PCEP
   message, while [RFC5553] makes extensions to RSVP-TE to carry the PKS
   in ERO and RRO objects. It is required that the PKS should also be
   allowed to be carried in the XRO in both PCEP message and RSVP-TE

6.1.2. Concurrent Computation of Working & Protection Path

   Alternatively, 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] allows requesting the PCE for path computation with
   specified protection type 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 problem 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 only request protection inside the core
   network, especially in case of single-homing. One UNI segment
   protection example is shown in Figure 8.

Zhang                  Expires September 2011                 [Page 13]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

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

                      Figure 8 - UNI segment recovery

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

   However, due to the overlay model, the source EN may not have the
   information concerning the CN to which the destination EN is attached.
   In other words, the source EN does not know which node is the merge
   node of the UNI segment protection, so the SERO object cannot be used
   to request the edge CN for the UNI segment recovery. Therefore,
   segment recovery may not be controlled explicitly by the source EN.

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 to control the set-up, release,
   modification and maintenance of sets of connections. 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 is simple and
   requires only minor extensions to connection signaling. However, if
   Calls are to be 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.

Zhang                  Expires September 2011                 [Page 14]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

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

   In this case, the source EN can raise a Call carrying the
   LINK_CAPABILITY object to have a capability exchange with the
   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.

Zhang                  Expires September 2011                 [Page 15]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

8. UNI Multicast

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

   In the scenarios where the overlay architectural model is used, it's
   a requirement to transport signals from one source EN to multiple
   destination ENs which are located in other overlay networks. One
   could create multiple point-to-point connections between the source
   EN and each destination EN, but it will be a waste of bandwidth
   resource of both UNI links and the core network.

   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 the multicast.
   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 9.

            |              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 9 - Only ingress/egress CNs support multicast

Zhang                  Expires September 2011                 [Page 16]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

   For example, in the PSC over TDM multi-layer scenario, the
   ingress/egress CNs may have the packet multicast capability and
   therefore can adapt the packets from EN into multiple TDM connections
   inside the core network, while other CNs inside the core network may
   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 10.

            |              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 10 - 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 multicast may also happen at the
   source EN in the multi-homing scenario. In this case, each branch of
   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.

Zhang                  Expires September 2011                 [Page 17]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

   For the flat model, one end-to-end P2MP session as described in
   [RFC4875] can be used directly 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.

   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 hierarchy 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 P2MP LSP. GMPLS UNI signaling
   should have the capability to convey the multicast information by
   using hierarchy 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] and other related standards 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

Zhang                  Expires September 2011                 [Page 18]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

11. Acknowledgments


12. References

12.1. Normative References

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

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

Zhang                  Expires September 2011                 [Page 19]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

   [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

   [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

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

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

Zhang                  Expires September 2011                 [Page 20]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 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).

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

   [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,

   [PCE-GMPLS] C. Margaria et al, "PCEP extensions for GMPLS", draft-
               ietf-pce-gmpls-pcep-extensions-01.txt, October 24, 2010

   [SRLG-FA]   Fatai Zhang et al, "RSVP-TE Extensions for Configuration
               SRLG of an FA", draft-zhang-ccamp-srlg-fa-configuration-
               01.txt, October 20, 2010.

Zhang                  Expires September 2011                 [Page 21]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

   [VCAT]      G. Bernstein et al, "Operating Virtual Concatenation
               (VCAT) and the Link Capacity Adjustment Scheme (LCAS)
               with Generalized Multi-Protocol Label Switching (GMPLS)",
               draft-ietf-ccamp-gmpls-vcat-lcas-11.txt, March 9, 2011.

13. 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
   Email: zhangfatai@huawei.com

   Oscar Gonzalez de Dios
   Telefonica Investigacion y Desarrollo
   Emilio Vargas 6
   Madrid,   28045

   Phone: +34 913374013
   Email: ogondio@tid.es

   Daniele Ceccarelli
   Via A. Negrone 1/A
   Genova - Sestri Ponente

   Email: daniele.ceccarelli@ericsson.com

   Greg M. Bernstein
   Grotto Networking
   Fremont California, USA

   Phone: (510) 573-2237
   Email: gregb@grotto-networking.com

Zhang                  Expires September 2011                 [Page 22]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

   Adrian Farrel
   Old Dog Consulting

   EMail: adrian@olddog.co.uk

   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

   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

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 September 2011                 [Page 23]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

   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

Zhang                  Expires September 2011                 [Page 24]

draft-zhang-ccamp-gmpls-uni-app-01.txt                       March 2011

Copyright Notice

   Copyright (c) 2010 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 September 2011                 [Page 25]

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