CCAMP C. Margaria, Ed. Internet-Draft Nokia Siemens Networks Intended status: Standards Track R. Casellas Expires: September 4, 2012 CTTC O. Gonzalez de Dios Telefonica Investigacion y Desarrollo March 03, 2012 Expressing Label Set in ERO draft-margaria-ccamp-label-set-ero-00 Abstract The paths chosen by Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) can be constrained using the Explicit Route (ERO) object and related sub-objects. Standard ERO sub-objects can specify the Autonomous System (AS), LSR Node Ids, Numbered or unnumbered TE links, downstream and upstream labels, and PCE path keys thus restricting which resources are to be used by a TE-LSP. The Explicit Label Control (ELC) in the explicit route object (ERO) allows both terminating an LSP on a particular outgoing port and label of an egress node, as well as restricting which label to use on any hop along the path determined by the route. However, currently, its not allowed to specify more than 2 labels (downstream and upstream label), and it is not possible to specify, for a given section or segment of a TE-LSP path, a set of labels to restrict which label to be allocated from a Set of candidate labels. This memo provides extensions to the RSVP-TE and PCEP protocols to support Label Sets in the form of ERO sub-objects, being applicable to ERO and ERO-like (IRO, RRO, XRO) sub-objects, extending the ELC concept to a set of candidate labels. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any Margaria, et al. Expires September 4, 2012 [Page 1] Internet-Draft Expressing Label Set in ERO March 2012 time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 4, 2012. Copyright Notice 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. Margaria, et al. Expires September 4, 2012 [Page 2] Internet-Draft Expressing Label Set in ERO March 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 5 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Solution overview . . . . . . . . . . . . . . . . . . . . . . 6 3. Multiple consecutive Label ERO subobjects . . . . . . . . . . 7 4. Label Set ERO subobject . . . . . . . . . . . . . . . . . . . 8 4.1. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 8 5. LSP_ATTRIBUTE extensions . . . . . . . . . . . . . . . . . . . 10 5.1. TARGETED_LSP_ATTRIBUTE TLV . . . . . . . . . . . . . . . . 10 5.2. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . 13 6. Evaluation of proposed solution alternatives . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7.1. Label Set ERO subobject . . . . . . . . . . . . . . . . . 15 7.2. LSP_ATTRIBUTE . . . . . . . . . . . . . . . . . . . . . . 15 7.2.1. Attribute Flags . . . . . . . . . . . . . . . . . . . 15 7.2.2. Service ID TLV . . . . . . . . . . . . . . . . . . . . 15 7.2.3. Targeted LSP attribute TLV . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Margaria, et al. Expires September 4, 2012 [Page 3] Internet-Draft Expressing Label Set in ERO March 2012 1. Introduction Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) can be route-constrained by making use of the Explicit Route (ERO) object and related sub-objects as defined in [RFC3209], [RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. In general, ERO sub-objects identify the resources to be used by a GMPLS, and can be used to restrict, exclude (IRO/XRO), define (ERO) or report (RRO) such resources. The Explicit Label Control (ELC) in the explicit route object (ERO) allows both terminating an LSP on a particular outgoing port and label of an egress node, as well as restricting which label to use on any hop along the path determined by the route. However, currently, its not allowed to specify more than 2 labels (downstream and upstream label), and it is not possible to specify, for a given section or segment of a TE-LSP path, a set of labels to restrict which label to be allocated from a Set of candidate labels. On the other hand, [RFC3473] defines the RSVP-TE LABEL_SET object, which can be used in a Path Message to restrict the choice of the generalized label, allocated by the downstream node to a set of labels. Extending the semantics of the Explicit Label Control to a label set and restricting / limiting the choice of label within a given Label Set, while maintaining the applicability of ERO and ERO-like RSVP-TE and PCEP objects can be beneficial in the following cases: o To constrain and restrict the choice of a Label at a given port (including egress port) to be selected from a set of labels but without strictly enforcing a single value (for example, when conveying a set of available labels due to hardware limitations such as tunable wavelengths). o Due to known label switching constraint on some section of the TE- LSP path: explicitly specify the label constraint on a specific link by requesting a Label Set to limit the choice of the label. o To constraint a distributed wavelength assignment (D-WA) for a TE- LSP DWDM transparent optical section o To allow a PCE or any other centralized entity to indicate a set of labels to be used in signaling, not only in the initial Label set but in any hop along the path. o To allow a Path Computation Client (PCC) to indicate, as an input constraint when requesting a combined R&WA computation to a PCE, Margaria, et al. Expires September 4, 2012 [Page 4] Internet-Draft Expressing Label Set in ERO March 2012 which set of wavelengths are acceptable at a given TE link, transparent segment or end-to-end path, depending on the label (wavelength) continuity restrictions of the underlying data plane. o To exclude (i.e., in a XRO object) a set of Labels from being considered in a label allocation, reusing the efficient encoding that has been proposed for Label sets and Label set ERO sub- objects. o To control resource sharing for pre-planned protecting LSP, where one can indicate which labels should be shared in addition to the PPRO disjointness constraints. 1.1. Contributing Authors 1.2. Requirements Language 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 RFC 2119. Margaria, et al. Expires September 4, 2012 [Page 5] Internet-Draft Expressing Label Set in ERO March 2012 2. Solution overview In order to support specifying several labels as a potential set of labels to be used when allocating a label, several solutions are applicable and described in this document: Allowing several consecutive Label ERO subobjects in an ERO object. Defining a Label Set ERO subobject to be used in an ERO (and similar) object. Extending the LSP_ATTRIBUTES object with a new TLV targeting attributes at a given node. A short overview of each solution is provided in the next sections and an evaluation of each one on is provided afterwards. Margaria, et al. Expires September 4, 2012 [Page 6] Internet-Draft Expressing Label Set in ERO March 2012 3. Multiple consecutive Label ERO subobjects This approach would require relaxing the rules that define how Label sub-objects are used within an ERO/XRO/RRO object, and notably in what concerns Explicit Label Control. In particular, the procedure described in [RFC3473] section 5.1.1 is modified as follows: The following SHOULD NOT result in a "Bad EXPLICIT_ROUTE object" errors: For there to be two label subobjects with the same U-bit values It is allowed to have several consecutive Label subobects with the same U-bit values, which become equally valid alternatives for the downstream label. To support the label subobject, a node must check to see if one or more sub-objects following its associated address/interface sub- objects are label subobjects. If this is the case, the sub-objects are examined: a RSVP-TE LABEL_SET object (Type 36) is constructed with the values of the labels that have the U-bit cleared. This LABEL_SET object MUST be included in the outgoing Path message and MAY be splitted into several LABEL_SET objects (LABEL_SET for the downstream direction). Note that this LABEL_SET does not replace the existing LABEL_SET and MAY be merged with it. The new Label_Set objects included in the Path message do not replace existing Label_Set object. If the U-bit of the subobject being examined is set (1), then the set of value of the Label subobject with U bit set should be used to restrict the choice of the upstream label associated with the bidirectional LSP. If this label is not acceptable, a "Bad EXPLICIT_ROUTE object" error SHOULD be generated. If the label is acceptable, the assigned label is copied into a new Upstream_Label object. This Upstream_Label object MUST be included on the corresponding outgoing Path message. Margaria, et al. Expires September 4, 2012 [Page 7] Internet-Draft Expressing Label Set in ERO March 2012 4. Label Set ERO subobject In this solution a new Label Set subobject is defined. The Label Set ERO subobject is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length |U| Reserved | C-Type(1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Set | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [RFC3471] for a description of L,U and Label Set parameters. Type x Label Set Length The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always divisible by 4. C-Type The C-Type of the included Label Object. Copied from the Label Object. 4.1. Procedures The Label Set subobject follows a similar procedure to the aforementioned one that is used when several Label sub-objects are allowed. The Label Set subobject must follow a subobject identifying the link where the Label Set is applicable (a subobject containing a IP address or an interface identifier) or a previous Label Set subobject. Several Label Set subobject may be present. The following SHOULD result in "bad EXPLICIT_ROUTE object" errors: If the first Label Set subobject is not preceded by a subobject containing an IP address or an interface identifier associated with an output link On unidirectional LSP setup, for there to be a label set subobject with the U-bit set It is not allowed to mix Label Set and Label subobject. The following text is adapted from the Label subobject procedure described in [RFC3473] Margaria, et al. Expires September 4, 2012 [Page 8] Internet-Draft Expressing Label Set in ERO March 2012 To support the label set subobject, a node must check to see if the subobject following its associate address/interface is a label set subobject. If it is, the following subobjects are examined. If the U-bit of the subobject being examined is clear (0), then value of the label set is copied into a a RSVP-TE LABEL_SET object (Type 36). One LABEL_SET object MUST be included in the outgoing Path message. The LABEL-SET object MAY be splitted into several LABEL_SET objects or MAY be merged with the existing LABEL-SET objects of this LSP. If the U-bit of the subobject being examined is set (1), then value of the label set is used to choose the label to be used for upstream traffic associated with the bidirectional LSP. If this label is not acceptable, a "Bad EXPLICIT_ROUTE object" error SHOULD be generated. If the label set is acceptable and a label assigned, the label is copied into a new Upstream_Label object. This Upstream_Label object MUST be included on the corresponding outgoing Path message. After processing, the label set subobjects are removed from the ERO. Note an implication of the above procedures is that the label set subobject should never be the first subobject in a newly received message. If the label subobject is the the first subobject an a received ERO, then it SHOULD be treated as a "Bad strict node" error. Procedures by which an LSR at the head-end of an LSP obtains the information needed to construct the Label Set subobject are outside the scope of this document. Margaria, et al. Expires September 4, 2012 [Page 9] Internet-Draft Expressing Label Set in ERO March 2012 5. LSP_ATTRIBUTE extensions In order to indicate, at a given hop or interface within the ERO, a set of candidate labels to be used when selecting the generalized label, it is also possible to use LSP_ATTRIBUTE extensions [RFC5240] . To this end, the procedure to generate the outgoing RSVP-TE Path message LABEL_SET object from the information contained in the LSP_ATTRIBUTE is similar conceptually to the previous ones. The following new TLVs are required for this solution : o a TLV indicating attributes for a node/interface (one per node/ interface) o This TLV will contain sub-TLV, here: * Attribute Flag TLV * A Label Set TLV * Any Attribute TLV which are applicable to a specific Node/ interface A new flag should be defined for the Targeted LSP attribute, requiring this will then depend in which object this is added. The Label Set TLV also required a new flag, but it SHOULD NOT appear directly in the LSP_ATTRIBUTE, this solution add TLVs that can be scoped only to specific interface or node. The RRO subobject attribute processing is not modified, a Node MAY report all the bits from the Attribute flag TLV in LSP_ATTRIBUTES or/and LSP_REQUIERED_ATTRIBUTES or/and the Attribute flag TLV in the TARGETED_LSP_ATTRIBUTE TLV. 5.1. TARGETED_LSP_ATTRIBUTE TLV A new TLV is introduced, the TARGETED_LSP_ATTRIBUTE TLV, which is valid on Path message only in LSP_ATTRIBUTE and LSP_REQUIRED_ATTRIBUTES Object. Margaria, et al. Expires September 4, 2012 [Page 10] Internet-Draft Expressing Label Set in ERO March 2012 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Identifier Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Identifier (Variable) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type x Length The Length contains the total length of the subobject in bytes, including the Type and Length fields. This length must be a multiple of four and must be at least eight. Identifier Type The type of identifier used, currently the following types are defined: 0 IPv4 address 1 IPv6 address 2 Unnumbered address Identifier Depending on the Identifier type this field contains: IPv4 address A 32 bit IPv4 address IPv6 address A 128 bit IPv6 Address Unnumbered address A 64 bit field containing a 32 bit Node Id and 32 bit unnumbered address TLVs A list of TLVs An IPv4 Identifier type Margaria, et al. Expires September 4, 2012 [Page 11] Internet-Draft Expressing Label Set in ERO March 2012 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Identifier Type=0 (IPv4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An IPv6 Identifier type 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Identifier Type=1 (IPv6) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An Unnumbered interface identifier 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Identifier Type=2 (Unnumbered)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unnumbered interface id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Margaria, et al. Expires September 4, 2012 [Page 12] Internet-Draft Expressing Label Set in ERO March 2012 5.2. PCEP Extensions This solution does not fit to existing PCEP object, One possible solution would be to map the RSVP LSP_ATTRIBUTE logic to PCEP LSPA object and define a set of LSPA TLVs carrying relevant LSP_ATTRIBUTE TLVs. This is for further study. Margaria, et al. Expires September 4, 2012 [Page 13] Internet-Draft Expressing Label Set in ERO March 2012 6. Evaluation of proposed solution alternatives The First two solutions would easily allow a centralized entity such as a PCE or a NMS to add this per-hop constraints information but would imply a greater impact to existing deployments. Let us note that, in general, a PCE currently uses the existing ERO sub-objects (with different semantics) in the following PCEP sub-objects. o ERO - to indicate the result of a Path Computation given one or more requests. o IRO - to specify which elements, resources, etc. must be used in a path computation. o XRO - to specify which elements, resources, etc. must be excluded in a path computation. o RRO - to report of existing Paths Making use of the LSP_ATTRIBUTES would reduce the impact on existing deployment yet allow to mandate the support of the attribute if desired, but will introduce several source for Label information. Margaria, et al. Expires September 4, 2012 [Page 14] Internet-Draft Expressing Label Set in ERO March 2012 7. IANA Considerations 7.1. Label Set ERO subobject IANA is requested to make the following subobject allocations from the "EXPLICIT_ROUTE Subobject Type" registry. Sub-object type TBA Name Label Set Reference This document 7.2. LSP_ATTRIBUTE IANA is request to add the following information for each TLV in the RSVP TLV type identifier registry. o Whether allowed on TARGETED_LSP_ATTRIBUTE TLV The existing registry is modified for existing TLVs. 7.2.1. Attribute Flags The new TLV type definition is as follow o TLV Type = 1 o TLV Name = Attribute Flags TLV o Allowed on LSP_ATTRIBUTES object o Allowed on LSP_REQUIRED_ATTRIBUTES object o Allowed on TARGETED_LSP_ATTRIBUTE TLV 7.2.2. Service ID TLV The new TLV type definition is as follow o TLV Type = 1 o TLV Name = Attribute Flags TLV o Allowed on LSP_ATTRIBUTES object Margaria, et al. Expires September 4, 2012 [Page 15] Internet-Draft Expressing Label Set in ERO March 2012 o Not allowed on LSP_REQUIRED_ATTRIBUTES object o Not allowed on TARGETED_LSP_ATTRIBUTE TLV 7.2.3. Targeted LSP attribute TLV IANA is requested to make the following allocations from the RSVP Attribute TLV Space registry. o TLV Type = n o TLV Name = Targeted LSP attribute TLV o Allowed on LSP_ATTRIBUTES object o Allowed on LSP_REQUIRED_ATTRIBUTES object o Not allowed on TARGETED_LSP_ATTRIBUTE TLV IANA is request to make the following allocation from the RSVP Attribute Flags registry Bit Name Attribute Flags Attribute Flags RRO Reference No Path Resv 9 Targeted LSP Yes No Yes This Attribute document 10 Label Set Yes No No This document Margaria, et al. Expires September 4, 2012 [Page 16] Internet-Draft Expressing Label Set in ERO March 2012 8. Security Considerations None. Margaria, et al. Expires September 4, 2012 [Page 17] Internet-Draft Expressing Label Set in ERO March 2012 9. Contributing Authors Margaria, et al. Expires September 4, 2012 [Page 18] Internet-Draft Expressing Label Set in ERO March 2012 10. Acknowledgments The research leading to these results has received funding from the European Community's Seventh Framework Program FP7/2007-2013 under grant agreement no 247674. Margaria, et al. Expires September 4, 2012 [Page 19] Internet-Draft Expressing Label Set in ERO March 2012 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003. [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April 2007. [RFC5240] Joshi, B. and R. Bijlani, "Protocol Independent Multicast (PIM) Bootstrap Router MIB", RFC 5240, June 2008. [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009. [RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource Reservation Protocol (RSVP) Extensions for Path Key Support", RFC 5553, May 2009. 11.2. Informative References [I-D.ietf-pce-gmpls-aps-req] Caviglia, D., Zhang, F., Ogaki, K., and T. Otani, "Document:", draft-ietf-pce-gmpls-aps-req-05 (work in progress), January 2012. Margaria, et al. Expires September 4, 2012 [Page 20] Internet-Draft Expressing Label Set in ERO March 2012 Authors' Addresses Cyril Margaria (editor) Nokia Siemens Networks St Martin Strasse 76 Munich, 81541 Germany Phone: +49 89 5159 16934 Email: cyril.margaria@nsn.com Ramon Casellas CTTC Av. Carl Friedrich Gauss n.7 Castelldefels, Barcelona Spain Phone: +34 93 645 29 00 Email: ramon.casellas@cttc.es Oscar Gonzalez de Dios Telefonica Investigacion y Desarrollo C/ Emilio Vargas 6 Madrid, 28043 Spain Phone: +34 91 3374013 Email: ogondio@tid.es Margaria, et al. Expires September 4, 2012 [Page 21]