CCAMP Working Group V.Beeram (Ed) Internet Draft I.Bryskin Intended status: Standards Track W.Doonan ADVA Optical Networking J.Drake (Ed) G.Grammel Juniper Networks Manuel Paul Ruediger Kunze Deutsche Telekom Friedrich Armbruster Cyril Magaria NSN Oscar Gonzalez de Dios Telefonica Expires: September 12, 2012 March 12, 2012 GMPLS-UNI BCP draft-beeram-ccamp-gmpls-uni-bcp-01.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September, 2012. Copyright Notice Beeram, et al Expires September 10, 2012 [Page 1] Internet-Draft GMPLS-UNI BCP March 2012 Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document pools together the best current practices that are being used to apply the GMPLS Overlay model at the User-Network Interface (UNI) reference point (as defined in [G.8080]) Table of Contents 1. Introduction...................................................3 2. Multi-Layered Approach.........................................3 3. Traffic Engineering............................................4 3.1. Augmenting the Client-Layer Topology......................6 3.1.1. Virtual TE Links.....................................7 3.2. Macro SRLGs...............................................8 3.3. MELGs.....................................................9 3.4. Switching Constraints....................................10 4. Connection Setup..............................................10 5. Path computation aspects......................................11 6. L1VPNs........................................................12 7. Use cases.....................................................13 7.1. Service optimization and restoration in Multi-Layer Networks ..............................................................13 7.2. IP/MPLS Offloading with UNI automation...................14 7.3. Use of PCE and VNTM in Multilayer Network Operation......15 8. Security Considerations.......................................15 9. IANA Considerations...........................................15 10. References...................................................15 10.1. Normative References....................................15 10.2. Informative References..................................16 11. Acknowledgments..............................................16 Beeram, et al Expires September 10, 2012 [Page 2] Internet-Draft GMPLS-UNI BCP March 2012 1. Introduction Generalized Multiprotocol Label Switching (GMPLS) provides tools to create end-to-end services in various transport technologies. These tools can be used to support service management in different types of deployment models. [RFC 4208] discusses how GMPLS can be applied to the overlay model. There are a good number of implementations that have built on the basic concepts discussed in [RFC 4208] and have successfully demonstrated interoperability. This document is an attempt to pool together the best current practices that are being used to apply the GMPLS Overlay model at the User-Network Interface (UNI) reference point (as defined in [G.8080]). [RFC 4208] recommends the use of hierarchical service activation when GMPLS is used for the core network and section 7.3.3 of [RFC4847], "Virtual Link Service Model" augments this by introducing a representation of server-layer network resources into a client- layer network topology. This memo explains how this augmentation enhances client-layer networking in an overlay model. The concepts discussed in this document are based primarily on experiences drawn from interoperating GMPLS-enabled IP routers with Optical Transport elements, but any GMPLS supported technology may be used in the client and server-layer networks. 2. Multi-Layered Approach When an end-to-end service crosses a boundary between two regions of dissimilar transport technology, it is necessary to execute distinct forms of service activation within each region. Fig 1: Sample Hybrid Topology (See PDF version) For example, in the hybrid network illustrated in Fig 1, provisioning a transport service between two GMPLS-enabled IP routers on either side of the optical WDM transport topology requires operations in two distinct layer networks; the client-layer network interconnecting the routers themselves, and the server-layer network interconnecting the optical transport elements in between the routers. Beeram, et al Expires September 10, 2012 [Page 3] Internet-Draft GMPLS-UNI BCP March 2012 Activation of the end-to-end service begins with a path determination process, followed by the initiation of a signaling process from the ingress along the determined path, per the set of figures shown in Fig 2. Fig 2: Hierarchical Service Action (see PDF version) 3. Traffic Engineering The previous section outlines the basic method for activating end- to-end services across a multi-layer network. As a necessary part of that process an initial path selection process was performed, whereby an appropriate path between the desired endpoints was determined through some means. Further, per expectations set through current practices with regard to service provisioning in homogeneous networks, operators expect that the underlying control plane system will provide automated mechanisms for computing the desired path or paths between network endpoints. In particular, operators do not expect under normal circumstances to be required to explicitly specify the end-to-end path; rather, operators expect to be able to specify just the endpoints of the path and rely on an automated computational process to identify and qualify all the elements and links on the path between them. Hence when operating a hybrid network such as that described in Fig 1, it is necessary to extend existing traffic engineering and path computation mechanisms to operate in a similar manner. Path computation and qualification operations occur at the path computation element (PCE) selected by ingress element of an end-to- end service. In order to be able to compute and qualify paths, the PCE must SHOULD be provided with information regarding the traffic engineering capabilities of the layer network to which it is associated, in particular the topology of the layer network and what layer-specific transport capabilities exist at the various nodes and links in that topology. It is important to note that topology information is layer-specific; e.g. path computation and qualification operations occur within a given layer, and hence information about topology and resource availability are required for the specific layer to which the connection belongs. The topology and resource availability information required by elements in the client-layer is quite distinct from that required by the elements in the server-layer Beeram, et al Expires September 10, 2012 [Page 4] Internet-Draft GMPLS-UNI BCP March 2012 network. Hence, the server-layer traffic engineering links are of no importance for the client-layer network, and it is actually desirable to block their advertisements into the client TE domain by the server-layer border nodes. For example, in the sample hybrid network (Fig 1) there are multiple optical transport elements supporting the connection between the GMPLS-enabled IP routers, and hence the physical topology between them includes several nodes and links. However, the optical elements between the IP routers are not able to switch traffic within the client-layer network of routers (e.g. IP/MPLS), as the optical elements are lambda switches, not IP/MPLS switches. Hence while the intervening optical elements may physically exist along the path, they are not a part of the topology available to the IP/MPLS routers for the purposes of traffic engineering in the client-layer network. An example of what the client-layer Traffic Engineering topology would look like for the sample hybrid network is shown in the top half of Fig 3. Fig 3: Traffic Engineering - ERO with "loose hop" (See PDF version) In this example, the TE topology associated with the client-layer network is indicated by the links and nodes colored yellow, whereas the TE topology associated with the server-layer network is indicated by the links and nodes colored green. The nodes at the edge of the server-layer network are visible in both the topologies. The yellow topology is capable of switching traffic within the client-layer, whereas the green topology is capable of switching traffic within the server-layer. In this example, if the "B" router attempts to determine a path to the "D" router it will be unable to do so, as the yellow topology to which the B and D routers is connected does not include a fully- yellow path between them. The only way to setup an end-to-end path in this case is to use an ERO with a "loose hop" across the server- layer domain as illustrated in Fig 3. This would cause the server- layer to create the necessary link in the client-layer topology on the fly. However, this approach has a few drawbacks - [a] the necessity for the operator to specify the ERO with the "loose" hop; [b] potential sub-optimal usage of server-layer network resources; and [c] unpredictability with regard to the fate-sharing of the new Beeram, et al Expires September 10, 2012 [Page 5] Internet-Draft GMPLS-UNI BCP March 2012 link (that is created on the fly) with other links of the client- layer topology. In order to be able to compute an end-to-end path between the two client-layer endpoints, the yellow topology MUST be sufficiently augmented to indicate where there are paths through the green topology which can provide connectivity between nodes in the yellow topology. In other words, in order for a client to compute path(s) across the server-layer network to other clients, the feasible paths across the server-layer network SHOULD be periodically computed by the server-layer network and made available (in terms of TE links and nodes that exist in the client-layer network) to all the clients. This is discussed in detail in the next section. In the overlay model the client and network domains, generally speaking, exist in separate layer networks. One important use case, however, is when the client and network topologies are in the same layer network. For example, IP routers that are connected via GMPLS UNI to a WDM network may be capable of terminating optical trails that are lambda switched by the network. Because the network domain normally would not want to leak its actual topology information into the client domain, clients would not be able to compute end-to-end paths across the network domain despite that client and network links belong to the same (WDM) layer network. The method described in the following sections of this document solves the problem of partitioned client topology for this case as well. 3.1. Augmenting the Client-Layer Topology In the example hybrid network shown below in Fig 4, consider a scenario where each GMPLS-enabled IP router is connected to the optical WDM transport network via a transponder. Further consider the situation where the transponder at node F can be connected to the transponder in node J via the optical path F-G-H-J. A lambda LSP can be provisioned in the server-layer along this path, and then advertised as a TE link into the client-layer. With the availability of this link, the path computation function at node A is able to compute an end-to-end path from A to C. Fig 4: Traffic Engineering - End to End Path Computation (See PDF version) Beeram, et al Expires September 10, 2012 [Page 6] Internet-Draft GMPLS-UNI BCP March 2012 In this case, in order for the TE link to be made available in the client-layer network topology, the network resources corresponding to the underlying server-layer LSP MUST be fully provisioned beforehand. As another scenario, consider a network configuration where the transponders at nodes E, F, J and I are connected to each other via directionless ROADM components. It is physically possible to connect any transponder to any other transponder in the server-layer network. As there are transport capabilities available in the server-layer network between every element containing an adaptation function to the client-layer network, the operator in this case would not wish to reserve any network resources in the server-layer network until a client LSP is signaled. The next section proposes a method to address this common operational requirement. 3.1.1. Virtual TE Links A "Virtual TE Link" as defined in section 7.3.3 of [RFC4847] is a TE link that is advertised into the client-layer network, with the available but not necessarily reserved/commuted resources in the server-layer network necessary to support that TE link. In other words, "Virtual TE Links" represent specific transport capabilities available in the server-layer network which can support the establishment of LSPs in the client-layer network. The two fundamental properties of a Virtual TE Link are: [a] it is advertised just like a real TE link and thus contributes to the buildup of the client-layer network topology; and [b] it does not require allocation of resources at the server-layer until used, thus allowing the sharing of server-layer network resources with other Virtual TE links. Fig 5: Traffic Engineering - End to End Path Computation (w/ "Virtual TE Links") (See PDF version) In the example shown in Fig 5, the availability of a lambda channel along the path F-G-H-J results in the advertisement by nodes F and J of a Virtual TE Link between F and J into the client-layer network topology (yellow line). With the advertisement of this Virtual TE Beeram, et al Expires September 10, 2012 [Page 7] Internet-Draft GMPLS-UNI BCP March 2012 Link, the path computation function at node A is able to compute an end-to-end path from A to C. Whenever a Virtual TE Link gets selected and signaled in the ERO of a client-layer connection, it ceases temporarily to be "virtual" and transforms into a regular TE-link. When this transformation takes place, the clients will notice the change in the advertised available bandwidth of this TE-link. Also, all other Virtual TE links that share resources with the TE-link in question start advertising "zero" available bandwidth. Likewise, the TE network image reverts back to the original form as soon as the last client- layer connection, going through the TE link in question, is released, i.e. Virtual TE Link becomes "virtual" again 3.2. Macro SRLGs The Virtual TE links that are advertised into the client-layer network topology cannot be assumed to be totally independent. It is quite possible for a given Virtual TE Link to share fate with one or more other Virtual TE Link(s). This is because the underlying server-layer LSPs (real or potential) can traverse the same server- layer network link and/or node, and failure of any such shared link/node would make all such LSPs inoperable (along with the Virtual TE Links supported by the LSPs). If diverse end-to-end paths for client-layer LSPs are to be computed, the fate-sharing information of the Virtual TE Links needs to be taken into account. The standard way of addressing this problem is to use SRLGs as a part of Virtual TE Link advertisements. A traditional SRLG represents a shared physical network resource upon which normal function of a link depends. Such SRLGs can also be referred to as physical SRLGs. Zero, one or more physical SRLGs could be identified and advertised for every TE link in a given layer network. However, there is a scalability issue with physical SRLGs in multi-layer environments. For example, if a WDM layer LSP serves an IP layer link, every WDM link and node traversed by the LSP MUST be considered as a separate SRLG. The number of SRLGs to be advertised to client (e.g. IP) layer per TE link would be directly proportional to the number of hops traversed by the underlying server-layer LSP. The notion of Macro SRLGs addresses this scaling problem. Macro SRLGs have the same protocol format as their physical counterparts and can be assigned automatically for each Virtual TE Link that is advertised into the client-layer network as a result of the existence of an underlying server-layer LSP (instantiated or Beeram, et al Expires September 10, 2012 [Page 8] Internet-Draft GMPLS-UNI BCP March 2012 otherwise). A Macro SRLG represents a set of shared path segments that are traversed by two or more of the underlying server-layer LSPs. Each shared path segment can be viewed as a sequence of shared resources where each individual resource has a physical SRLG associated with it (example depicted in Fig 6). The actual procedure for deriving these Macro SRLGs is beyond the scope of this document. Fig 6: Macro SRLGs (See PDF version) 3.3. MELGs If two or more Virtual TE Links share fate, it means that the links could be concurrently activated and used by client LSPs with a caveat that the links could be taken out of service by a single network failure, and, thus, cannot be used in the same protection scheme. There could be a stronger (than fate sharing) relationship between two or more Virtual TE Links. Because a set of Virtual TE Links could be mapped onto the same uncommitted network resources, the situation can arise when only one Virtual TE Link from the set could be activated at any given time. In other words, two or more Virtual TE Links could be mutually exclusive. One example of mutually exclusive Virtual TE Links is when the paths for the network domain LSPs supporting the Virtual TE Links not only intersect, but also require usage of the same resource (e.g. lambda channel) on the intersection. Another example is when the said paths depend on a common physical resource (e.g. transponder, regenerator, wavelength converter, etc.) that could be used only by one LSP at a time. For a client path computation function (especially a centralized one capable of concurrent computation of multiple end-to-end paths) it is important to know about such mutually exclusive relationship between Virtual TE Links. This memo introduces a concept of Mutually Exclusive Link Group (MELG) and suggests a new sub-TLV - MELGs sub- TLV - to be added to the top level TE Link TLV. The purpose of the MELGs sub-TLV is: - To indicate via a separate network unique number (MELG ID) an element or a situation that makes the advertised Virtual TE Link to belong to one or more mutually exclusive link groups. Path computer will be able to decide on whether two or more Virtual TE Links are mutually exclusive or not by finding the overlap of Beeram, et al Expires September 10, 2012 [Page 9] Internet-Draft GMPLS-UNI BCP March 2012 advertised MELGs (similar to deciding on whether two or more TE Links share fate or not by finding common SRLGs) - To indicate whether the advertised Virtual TE link is committed or not at the moment of the advertising. Such bit of information is important for a path computer: committing new Virtual TE links (vs. re-using committed ones) has a consequence of committing more network resources and disabling other Virtual TE links that have common MELGs with newly committed Virtual TE Link Exact format of the MELGs sub-TLV is described in [MELG] [TBD: MELG Figure/Example] 3.4. Switching Constraints Certain types of network configurations necessitate the specification of connectivity constraints in the Virtual TE Link advertisements. If the switching constraints associated with the binding of Virtual and access TE links terminated on a given network border node do not get advertised into the client domain, there is a risk of an invalid path being computed (Fig 7). This document recommends the use of the extensions specified in [GEN_CNSTR] to address this issue. Fig 7: Switching Constraints (See PDF version) 4. Connection Setup Experience with control plane operations in multi-layer networks indicates there are benefits to coordinating certain signaling operations, in the following manner. Consider the scenario where the network domain is a WDM layer topology comprising of ROADMs. The set-up time for a service at the WDM layer can be fairly long, as it can involve time-consuming power-equalization procedures, amongst other layer-specific operations. This means that at very least, the setup timers for the client-layer service would need to be somehow coordinated with that of the server-layer service. To avoid this operationally awkward issue, a phased connection setup process as depicted in Fig 8 is proposed. Beeram, et al Expires September 10, 2012 [Page 10] Internet-Draft GMPLS-UNI BCP March 2012 Fig 8: Phased Connection Setup (See PDF version) As long as the LSP segment across the server-layer network is not completely "UP" (e.g., Fully Power Equalized), the nodes at the edge of the server-layer network through which the LSP passes would signal the client-layer PATH/RESV messages with the T (Testing) bit set in the ADMIN_STATUS. The T bit would be cleared in these messages only after the LSP segment across the server-layer network is deemed fully operable. 5. Path computation aspects It is assumed that a client domain path computation function makes use of advertised client domain TE links as well as Virtual TE Links while computing end-to-end paths for client LSPs. The said path computation function could be local (i.e. located on client LSP ingress nodes, (Corresponding to RFC4655 Composite PCE node) or remote (i.e. network/External PCEs). Path computations could be triggered by client nodes or NMS. Generally speaking, the responsibility of the client domain path computation function is to compute one or two paths for each source-destination pair of the TE- LSPs. Path computation SHOULD be subject to one or more path optimization criterions (such as shortest path, minimal latency, etc.) and path computation constraints (e.g. link unreserved bandwidth, link colors, layer-specific constraints, explicit exclusions, etc.) As the augmented topology does hide server layer links and nodes, it is RECOMMENDED to support SRLG diverse path computation. Furthermore the path computation SHOULD consider the connectivity and switching constraint in addition to all usual TE path computation constraints (e.g. unreserved bandwidth, link colors, layer-specific constraint) when available. When using PCE architecture and PCEP protocol those aspects are covered by RFC5440, RFC5521 and RFC5541. As described in section 3.3. Virtual TE link may not only share risk but may also depend on the same also server layer resources, thus creating mutual exclusivity between Virtual TE Links. Therefore, network topologies containing Virtual TE links have an increased probability of LSP setup failures. In such topologies concurrent path computation that takes in consideration MELG will reduce Beeram, et al Expires September 10, 2012 [Page 11] Internet-Draft GMPLS-UNI BCP March 2012 signaling failures (Not considering MELGs may result, for example, in two LSPs routed on two Virtual TE-Links sharing the same server layer resource). PCEP supports concurrent path computation per RFC5440, expressing MELG constraint is out of scope of this document (defined in [MELG]) Core domain path computation and Inter-PCE path computation is out of scope for this document. 6. L1VPNs [RFC4208] implies that multiple independent sets of clients, located in the same or different layer networks, could be connected to the same network domain, providing the connectivity between the clients within each set, while blocking the connectivity between the clients from different sets (i.e. allows for the L1VPNs application). This document suggests: - New sub-TLV - VPN IDs sub-TLV - to be added to the top level TE Link TLV. Exact format of the VPN IDs sub-TLV is described in [GMPLS UNI RTG] - Configuring on the network end of each access TE link zero, one or more network unique VPN IDs and adding the configured information as VPN IDs sub-TLV to the TE link advertisement; - Configuring zero, one or more network unique VPN IDs for each Virtual TE Link and adding the configured information as VPN IDs sub-TLV to the TE link advertisement; - Making the network responsible for proper filtering of the TE Link advertisements, so that the information pertinent to VPN X is leaked only to the clients that are members of the said VPN X This approach would achieve the following: - Automatic VPN member auto-discovery; - Providing to the clients VPN specific view of the network ; - Partitioning network resources between VPNs; - Ensuring successful path computations (and therefore connectivity) only between members of the same VPN [RFC4208] implies that access TE Links could be named from a single or a separate (per-VPN) name space. This draft takes the former approach, that is, regardless of the associated VPNs, all access and Virtual TE Links MUST be named from the same (specifically, network) name space. Apart from simplicity, one reason for such choice is the following consideration: a GMPLS LSP established between a pair of Beeram, et al Expires September 10, 2012 [Page 12] Internet-Draft GMPLS-UNI BCP March 2012 clients is likely to be advertised as a TE Link into the client's layer TE domain. For example, a GMPLS LSP established between a pair of IP routers is likely to be advertised as a TE Link into IP/MPLS layer TE domain. This means that neither access nor Virtual TE Links belong to the "real" client layer network. Hence assigning addresses for access and Virtual TE links from the network name space would not cause address collisions/re-configurations in the client layer. [TBD: L1VPN Figure/Example] 7. Use cases 7.1. Service optimization and restoration in Multi-Layer Networks Multi-layer networks, as described in this document, are a reality today and they are operated by different groups following different operational procedures. This requires an independent optimization of the client and server layer networks, and this could lead to the situation where the re- routing of a client layer LSP fails because some of the resources on the selected alternate path share fate with some of the resources on the LSP's failed path. This would happen due to lack of knowledge of the server layer network when the client layer path computation function selects the alternative path. The high percentage of IP traffic in operator networks today makes it necessary that client and server layer share sufficient information to enable an optimized transport for IP/MPLS services and address existing inefficiencies. One important point from the carrier perspective is that the usage of server-layer SRLG information by the client layer path computation is essential to address these issues. In a typical multi-layer network, in which the IP/MPLS network is the client network and the WDM/OTN network is the server network, it is the client layer network that is responsible for the protection of the IP/MPLS traffic using mechanisms such as FRR and/or LFA. Regardless of the mechanism that is used, SRLG information from the server layer network helps to optimize the client layer network with respect to reduced link utilization and reliable and efficient protection of the client traffic. Beeram, et al Expires September 10, 2012 [Page 13] Internet-Draft GMPLS-UNI BCP March 2012 Today server layer network SRLGs are used mainly to calculate diverse alternative paths for the IP/MPLS client layer network. Therefore the following procedure MUST be periodically performed: - Build traffic matrix for the server layer network (based on IP links) - Solve traffic engineering problems in the server layer network - Calculate new SRLGs for the client layer network - Simulate failure scenarios GMPLS UNI reduces the OPEX costs of doing these procedures manually by providing: - the advertisement of server layer network SRLG information into client layer network via common routing protocol - the client layer network path computation function uses this SRLG information in selecting maximally diverse paths. 7.2. IP/MPLS Offloading with UNI automation A typical application in multi-layer (IP/MPLS over optical) networks is termed 'IP Offloading', in which the network responds to the increase in traffic of a particular service or across a network segment in the IP network by placing IP traffic into GMPLS LSPs in the server layer network in order to reduce the load on intermediate IP routers. The increase in traffic is typically caused by an elevated number of high traffic flows/services traversing an IP network segment, which requires core routers to forward large IP traffic volumes. The decision process driving IP offloading is complex and is constrained by a set of rules that reduce the cost of running the multi-layer network while ensuring that it remains stable. Automation of IP Offloading poses a number of challenges. It must establish GMPLS LSPs in the server layer (e.g. optical) network and automatically assign them identifiers, either numbered or unnumbered, in the client layer network. This information can be automatically exchanged using the procedures from [RFC 4203]. However, such procedures are not always implemented in commercial equipment. Consequently, this information may need to be configured manually as part of the initial set-up/installation of these LSPs. Beeram, et al Expires September 10, 2012 [Page 14] Internet-Draft GMPLS-UNI BCP March 2012 Later, when the GMPLS LSP tunnel needs to be established, the hierarchical TE Link addresses MUST be included in the UNI path request. 7.3. Use of PCE and VNTM in Multilayer Network Operation Two key elements have been proposed to help in the management and coordination of multi-layer networks: the Path Computation Element (PCE) and the Virtual Network Topology Manager (VNTM). PCE is responsible for the calculation of paths between endpoints, particularly in complex scenarios involving, for example, WDM layer physical impairments. VNTM is in charge of maintaining the topology of the client layer network by instantiating GMPLS LSPs, in the server layer network. I.e., in can be used to provide TE links to the client layer network in real time. Several cooperation modes between PCE, VNTM and the NMS have been proposed in [RFC 5623]. For instance, the operator can request a new MPLS path via the NMS, which consults a PCE with information of the multi-layer network. The PCE, in case that there are enough resources in the MPLS layer, returns a path made of real TE links. On the other hand, if there is a lack of resources at the MPLS layer, the response may contain a path with one or more Virtual TE- Links. In this case, the NMS can cooperate with the VNTM to suggest the set-up of a GMPLS LSP(s) in the server layer network. The VNTM, based on the local policies, can accept the suggestion and cause the set-up of the GMPLS LSPs in the server layer network. In order for the computation to be effective, the PCE needs knowledge of the augmented topology (SRLGs, MELGs, TE metrics of the Virtual TE-Links), which can be provided via GMPLS-UNI. 8. Security Considerations TBD 9. IANA Considerations This document has no actions for IANA. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Beeram, et al Expires September 10, 2012 [Page 15] Internet-Draft GMPLS-UNI BCP March 2012 [G.8080] Architecture for the automatically switched optical network (ASON) [RFC4208] G. Swallow, J.Drake, H. Ishimatsu, and Y. Rekhter, "GMPLS UNI: RSVP-TE Support for the Overlay Model", RFC 4208, October 2005. [MELG] Mutually Exclusive Link Group, [draft--melg-00.txt] [GEN CNSTR] G.Bernstein, Y.Lee, D.Li, W.Imajuku, "General Network Element Constraint Encoding for GMPLS Controlled Networks" [draft-ietf-ccamp-general-constraint-encode-07.txt] [GMPLS UNI RTG] GMPLS UNI Routing Extensions [draft--gmpls-uni-routing-00.txt] 10.2. Informative References [RFC4847] T. Takeda, "Framework and Requirements for Layer 1 VPNs", RFC 4847, April 2007. 11. Acknowledgments TBD Authors' Addresses Vishnu Pavan Beeram ADVA Optical Networking Email: vbeeram@advaoptical.com Igor Bryskin ADVA Optical Networking Email: ibryskin@advaoptical.com Wes Doonan Beeram, et al Expires September 10, 2012 [Page 16] Internet-Draft GMPLS-UNI BCP March 2012 ADVA Optical Networking Email: wdoonan@advaoptical.com John Drake Juniper Networks Email: jdrake@juniper.net Gert Grammel Juniper Networks Email: ggrammel@juniper.net Manuel Paul Deutsche Telekom Email: Manuel.Paul@telekom.de Ruediger Kunze Deutsche Telekom Email: Ruediger.Kunze@telekom.de Oscar Gonzalez de Dios Telefonica Email: ogondio@tid.es Cyril Margaria Nokia Siemens Networks Email: cyril.margaria@nsn.com Beeram, et al Expires September 10, 2012 [Page 17] Internet-Draft GMPLS-UNI BCP March 2012 Friedrich Armbruster Nokia Siemens Networks Email: friedrich.armbruster@nsn.com Beeram, et al Expires September 10, 2012 [Page 18]