Network Working Group Fatai Zhang Internet Draft Huawei Category: Informational O. Gonzalez de Dios Telefonica Investigacion y Desarrollo D. Ceccarelli Ericsson 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) draft-zhang-ccamp-gmpls-uni-app-01.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 14, 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 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", "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. 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 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 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 scenarios. 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 signaling. 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 known. 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 action. Zhang Expires September 2011 [Page 18] draft-zhang-ccamp-gmpls-uni-app-01.txt March 2011 11. Acknowledgments TBD. 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 2007. [RFC4874] CY. Lee et al, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC4874, April 2007. [RFC4875] R. Aggarwal et al, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)", RFC4875, May 2007. [RFC4974] D. Papadimitriou and A. Farrel, Ed., "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls", RFC4974, August 2007. [RFC5150] A. Ayyangar et al, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC5150, February 2008. [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 2008. [RFC5253] T. Takeda, Ed., "Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode", RFC 5253, July 2008. [RFC5339] JL. Le Roux et al, "Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC5339, September 2008. [RFC5441] JP. Vasseur et al, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC5441, April 2009. [RFC5623] Oki, E., Takeda, T., Le Roux, J.L., and Farrel, A., "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, September 2009. [RFC5920] L. Fang, Ed., "Security Framework for MPLS and GMPLS Networks", RFC5920, July 2010. [Call-ext] Fatai Zhang et al, "RSVP-TE extensions to GMPLS Calls", draft-zhang-ccamp-gmpls-call-extensions-01.txt, July 08, 2009. [PCE-GMPLS] C. Margaria et al, "PCEP extensions for GMPLS", draft- ietf-pce-gmpls-pcep-extensions-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 Spain Phone: +34 913374013 Email: ogondio@tid.es Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy 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 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 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 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Zhang Expires 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]