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

Versions: 00 01 02 03 04 05

Network Working Group                                        Fatai Zhang
Internet Draft                                                    Huawei
Category: Standards Track                            O. Gonzalez de Dios
                                   Telefonica Investigacion y Desarrollo
                                                            G. Bernstein
                                                       Grotto Networking
Expires: September 7, 2011                                 March 7, 2011


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

                  draft-zhang-ccamp-gmpls-uni-app-00.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 September 7, 2011.



Abstract

   Generalized Multiprotocol Label Switching (GMPLS) defines a series of
   protocols for the creation of Label Switched Paths (LSPs) in various
   switching technologies. The GMPLS UNI was developed in [RFC4208] in
   order to be applied to an overlay network model.






Zhang                  Expires September 2011                  [Page 1]


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


   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",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].



Table of Contents


   1. Introduction ................................................. 3
   2. Terminology .................................................. 4
   3. UNI Addressing ............................................... 4
   4. UNI Auto Discovery ........................................... 5
   5. UNI Path Computation ......................................... 6
      5.1. UNI Link Selection ...................................... 6
   6. UNI Path Provisioning ........................................ 7
      6.1. Flat Model .............................................. 7
      6.2. Stitching Model ......................................... 8
      6.3. Hierarchy Model ......................................... 9
   7. UNI Recovery ................................................. 9
      7.1. End-to-end Recovery .................................... 10
         7.1.1. Serial Provisioning of Working & Protection Path .. 10
         7.1.2. Concurrent Computation of Working & Protection Path 11
      7.2. Segment Recovery ....................................... 11
   8. UNI Call .................................................... 12
      8.1. Exchange of UNI Link Information ....................... 12
      8.2. Control of Call Route .................................. 13
   9. UNI Multicast ............................................... 13
      9.1. UNI Multicast Connection Provisioning .................. 15
   10. Security Considerations .................................... 15
   11. IANA Considerations ........................................ 15
   12. Acknowledgments ............................................ 15
   13. References ................................................. 16
   14. Authors' Addresses ......................................... 18





Zhang                  Expires September 2011                  [Page 2]


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


1. Introduction

   Generalized Multiprotocol Label Switching (GMPLS) defines a series of
   protocols, including Open Shortest Path Fist - Traffic Engineering
   (OSPF-TE) and Resource ReserVation Protocol - Traffic Engineering
   (RSVP-TE), 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]. 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 | |    |  |
   |  +----+ |     |                                  |     | +----+  |
   |         |     +----------------------------------+     |         |
   +---------+                Core Network                  +---------+
     Overlay                                                  Overlay
     Network                                                  Network

              Figure 1 - Applying GMPLS overlay model at UNI

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


Zhang                  Expires September 2011                  [Page 3]


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


   -  "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, which is similar to connection creation between
   two core nodes. When considering the isolation of topology
   information between core network and the overlay network, additional
   processing of the ERO and 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, the interface between client layer node and
   server layer node can be seen as a UNI. Or, when deploying VPN
   services, users can connect to a service provider network via 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.



2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].



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


Zhang                  Expires September 2011                  [Page 4]


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


   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.

   In the cases above, due to the address space incompatibility issues,
   the RSVP-TE [RFC3473] session may not be used to create the UNI
   connection. Hence [RFC4208] needs to be extended to support the
   different address space between Core network and Overlay network.



4. UNI Auto Discovery

   In most cases, the source EN does not have the knowledge of which CN
   the destination EN is attached and TE information concerning the
   destination UNI link. When creating the connection, information about
   the destination EN is carried in the signaling message sent to the
   ingress CN.

   The ingress CN is then responsible for resolving the address of the
   egress CN based on the destination EN information and examine whether
   there is sufficient resources on the destination UNI link. In other
   words, the CN should have the mapping relationship between CNs and
   ENs and the TE information of the corresponding UNI links. Therefore,
   some kind of UNI auto discovery or manual configuration is required.

   We can avoid manual configuration if the UNI is applied in a Layer 1
   Virtual Private Network (L1VPN, [RFC4847]) scenario. In this case 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 5]


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


5. UNI Path Computation

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

   The selection of UNI link 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. In such
   cases, the CN to which the source EN is attached, or the PCE
   ([RFC4655]) which is responsible for the core network, can perform
   the path computation for traversing the core network when the UNI
   signaling sent from the source EN reaches to the CN.

5.1. UNI Link Selection

   The source EN does not have the topology and TE information of the
   core network in the overlay model. Therefore, in the case of multi-
   homing, 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 to solve this
   problem in early GMPLS UNI deployments. The PCE can use the UNI
   discovery mechanism described in Section 4.  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. 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 6]


draft-zhang-ccamp-gmpls-uni-app-00.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

   In cases where the confidentiality of the topology within the core
   network needs to be preserved, the Path Key Subobject (PKS) can be
   used (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 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.

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

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


Zhang                  Expires September 2011                  [Page 7]


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


   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 (in the language of [RFC5251], such end-to-end RSVP session is
   called Shuffling Session), as shown in Figure 3.

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

                           Figure 3 - 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.

6.2. Stitching Model

   Alternatively, in the above case, 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 - Stitching model



Zhang                  Expires September 2011                  [Page 8]


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


6.3. 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 5 - 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.



7. UNI Recovery

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






Zhang                  Expires September 2011                  [Page 9]


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


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

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

                    Figure 6 - UNI end-to-end recovery



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



Zhang                  Expires September 2011                [Page 10]


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


   node ID and link ID and can be allowed to be known outside the core
   network.

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



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



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






Zhang                  Expires September 2011                [Page 11]


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


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

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



8. UNI Call

   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.

8.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 VCAT/LCAS capability of the destination EN may not
   be known.

   In this case, the source EN can raise a Call carrying the


Zhang                  Expires September 2011                [Page 12]


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


   LINK_CAPABILITY object to have a capability exchange with the
   destination EN, as described in [RFC4974].

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



9. UNI Multicast

   There is desired to support point-to-multipoint (P2MP) TE LSPs from
   one source EN to multiple leaf ENs.

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

   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


Zhang                  Expires September 2011                [Page 13]


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


   inside the core network, while other CNs inside the core network may
   only support point-to-point (P2P) TDM connections.

            +----------------------------------------+
            |              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

   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.

            +----------------------------------------+
            |              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


Zhang                  Expires September 2011                [Page 14]


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


   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.

9.1. UNI Multicast Connection Provisioning

   The three UNI connection provisioning models, as described in Section
   6, 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 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 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.



10. Security Considerations

   TBD.



11. IANA Considerations

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



12. Acknowledgments

   TBD.





Zhang                  Expires September 2011                [Page 15]


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


13. References

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

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

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

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

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

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

   [RFC5212]   K. Shiomoto et al, "Requirements for GMPLS-Based Multi-
               Region and Multi-Layer Networks (MRN/MLN)", RFC5212, 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.

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





Zhang                  Expires September 2011                [Page 16]


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


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

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

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

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

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

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

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

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

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

   [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 17]


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


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

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

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

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



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


   Greg M. Bernstein
   Grotto Networking
   Fremont California, USA

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


Zhang                  Expires September 2011                [Page 18]


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




   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


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



Zhang                  Expires September 2011                [Page 19]


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


   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.



Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.


Zhang                  Expires September 2011                [Page 20]


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


   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 21]


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