Network Working Group L. Andersson Internet-Draft A. Gavler Intended status: Experimental Acreo AB Expires: July 5, 2007 January 2007 Extenstion to RSVP-TE for GMPLS Controlled Ethernet - An experimental approach draft-andersson-gels-exp-rsvp-te-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 July 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Andersson & Gavler Expires July 5, 2007 [Page 1] Internet-Draft A GELS Experiment January 2007 Abstract This document specifies the extensions to RSVP-TE that Acreo AB has used in the GMPLS part of testbed. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. GMPLS Controlled Ethernet research . . . . . . . . . . . . . . 4 2.1. The Acreo National Broadband Testbed . . . . . . . . . . . 4 2.2. Ethernet Control Plane . . . . . . . . . . . . . . . . . . 4 2.3. The Ethernet data plane . . . . . . . . . . . . . . . . . 4 2.4. Motivation for a GMPLS controlled Ethernet . . . . . . . . 5 2.5. Incremental development . . . . . . . . . . . . . . . . . 5 3. Protocol extensions . . . . . . . . . . . . . . . . . . . . . 7 3.1. Information in the Generalized Label Request Object . . . 7 3.2. Label Definition . . . . . . . . . . . . . . . . . . . . . 7 3.3. Extensions to the Session Attribute Object . . . . . . . . 8 3.4. Suggested Label Object . . . . . . . . . . . . . . . . . . 9 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Andersson & Gavler Expires July 5, 2007 [Page 2] Internet-Draft A GELS Experiment January 2007 1. Introduction This Internet Draft documents the extensions to RSVP-TE that were used in the tests of GMPLS Controlled Ethernet (GELS), which were performed in the Acreo National Broadband Testbed end of 2006 and early 2007. In Section 2 we give a short background of the research in the test bed in general and the GMPLS controlled Ethernet in particular. Note: The -01 draft has been updated after comments on the gels mailing list, and does when it is written not exactly match our implementation. 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 [RFC2119]. Andersson & Gavler Expires July 5, 2007 [Page 3] Internet-Draft A GELS Experiment January 2007 2. GMPLS Controlled Ethernet research 2.1. The Acreo National Broadband Testbed The Acreo National Broadband Testbed (ANBT) has been set up a joint effort by the Swedish government and the Swedish industry. Acreo AB was chosen to host the test bed, and the task is to initiate research projects on different aspects of broadband networks. Methods for control of carrier Ethernet has attracted quite a bit of interest. GELS test bed is subset of the ABNT and consists of a 6 GMPLS enabled IP routers and 4 Ethernet Bridges. In some of our tests we've also used Linux based SW Ethernet Bridges. 2.2. Ethernet Control Plane The control plane as implemented in the ANBT consists of three different parts: o Routing Protocol - OSPF-TE, we are running the OSPF-TE exactly as implemented by the Dragon project. o Signaling protocol - RSVP-TE, we have made the extensions to RSVP-TE, RFC3471 [RFC3471] and RFC3473 [RFC3473] as specified in Section 3. o Link Management Protocol - LMP, we have not yet implemented the LMP protocol. 2.3. The Ethernet data plane In the test bed we have used the Ethernet data plane as specified in IEEE Std 802.1Q. This has been made possible since we control the entire network by a GMPLS control plane and by default set up loop free LSPs. We have no traffic entering the network that results in that flooding or learning is triggered. This is clearly an artificial condition, but it is very well acceptable in a research network. To take GELS into production networks is outside the scope of the current work we've undertaken, our focus is to establish a test bed e.g. for tests of new control plane extensions, traffic engineering paradigms and advanced applications. To run a GMPLS control plane for a production network will quite possibly require 802.1Q S-VLAN tags as specified in the IEEE Std 802.1ad Provider Bridging amendment to IEEE Std 802.1Q. and possibly the future IEEE802.1ah standard. Andersson & Gavler Expires July 5, 2007 [Page 4] Internet-Draft A GELS Experiment January 2007 2.4. Motivation for a GMPLS controlled Ethernet The answer to question "Why GELS?" is simple from a research perspective. Very much of research starts from the question "What happens if ...?" In this case the question was "What happens if we make use of an GMPLS control plane to control an Ethernet network?" The answer to that question will decide whether we'll continue using GELS a as configuration tool while setting up tests in our network. Two tentative results today is that (1) for the application we have it is working well and saves us time, and (2) that we will look into the possibility to control every dynamic or configurable technology by the GMPLS control plane. In addition to this we also have a number of external parties interested in GELS. We have not been the only party active in this area, we have had a number of communications with e.g. Dave Allan, Don Fedyk, Dimitri Papadimitriou, Adrian Farrel, Attila Takacs, Deborah Brungard, Jai Hyung Cho and Nurit Sprecher. They have not reviewed this document, but nevertheless have had influence on our thinking on the subject. This is the major reason to share what we've been doing. We are also in debt to the Dragon project, that gave us a good start when we could use their open source code as a starting point. 2.5. Incremental development Our general approach to GELS has been stable over time, we've wanted to use the possibility to statically configure Ethernet Bridges by means of a GMPLS signalling protocol and to learn network topology and traffic engineering information by means of OSPF-TE. One thing has been changing though; our understanding what the "Ethernet label" is and how it can be used. o Our first approach was that it would be possible to define a new Tag Protocol Identifier (tpid) that should have pointed to "Ethernet Label" rather than a 802.1Q VLAN tag. Since this idea involved major changes to the Ethernet data plane, the Ethernet Standards and existing implementations this idea were quickly dropped. However we were able to prove that the concept works on off the shelf equipment. o Our second approach was to simply use the 802.1Q VLAN tag, but due to scalability problems (4096 labels per network) we wanted to Andersson & Gavler Expires July 5, 2007 [Page 5] Internet-Draft A GELS Experiment January 2007 swap them per link. The IEEE802.1 have made it very clear this also breaks existing IEEE standards. However, communications from IEEE802.1 have opened up for a certain type of VID swapping. There are indication that the idea of VID swapping, which is accepted at certain types of interface, might be increasingly accepted in the future. o At this point a number of ideas started to emerge from a lot of different sources. Today we are convinced that an Ethernet tag should be possible to use as an Ethernet label, often in combination with the destination MAC Address. Further we are mostly looking to 802.1Q S-VLAN tags as defined in IEEE Std 802.1ad Provider Bridging amendment to IEEE Std 802.1Q. It is possible that when the IEEE Std 802.1ah is ready the new tag defined there will be possible to use. o Our current network works with standard 802.1Q bridges. Andersson & Gavler Expires July 5, 2007 [Page 6] Internet-Draft A GELS Experiment January 2007 3. Protocol extensions Taking a starting point in RFC3471 [RFC3471] and RFC3473 [RFC3473] we have made the following extensions and adaptations to RSVP-TE. 3.1. Information in the Generalized Label Request Object The required information to be carried by a PATH message in the Label Request Object is defined in RFC3471, and the format of the Label Request Object is defined in RFC3473 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num (19)| C-Type (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Enc. Type |Switching Type | G-PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For the purpose of GELS we use the following encoding of the Label Request Object: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num (19)| C-Type (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet (2) | L2SC(51) | G-PID (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is according to the parameter definitions in RFC3471. 3.2. Label Definition The format of a Generalized Label object is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num (16)| C-Type (2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | | ... | Andersson & Gavler Expires July 5, 2007 [Page 7] Internet-Draft A GELS Experiment January 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ We have defined the Ethernet Label object 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num (16)| C-Type (2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | resv | VID (12) | DA MAC ADDRESS (16/48) | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DA MAC ADDRESS (32/48) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The four most significant bits of the Label field is not used and should be set to 0 went sent and ignored when received. 3.3. Extensions to the Session Attribute Object The Session Attribute Object is optional and carried in the PATH message. In RFC3209 [RFC3209] the Session Attribute Object is defined. The Session Attribute Class is 207. RFC3209 also defines two C_Types, LSP_TUNNEL, C-Type = 7 and LSP_TUNNEL_RA, C-Type = 1. The LSP_TUNNEL_RA C-Type includes all the same fields as the LSP_TUNNEL C-Type. Additionally it carries resource affinity information. This document defines a third format LSP_TUNNEL_ETH, the C-type = 12. The LSP_TUNNEL_ETH C-type carries all the same fields as the LSP_TUNNEL_RA C-type. Additionally it carries Ethernet LSP attribute information. We have defined the LSP_TUNNEL_ETH C-type as follows. The Session Attribute Class is 207 and the LSP_TUNNEL_ETH, the C-type is 12. Andersson & Gavler Expires July 5, 2007 [Page 8] Internet-Draft A GELS Experiment January 2007 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet Flags |T|M|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exclude-any | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Include-any | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Include-all | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Setup Prio | Holding Prio | Flags | Name Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Session Name (NULL padded display string) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T = type bit, 1 indicates that both VID and DA MAC address is used, 0 indicates that only VID is used. M = merge bit, 1 indicates that merging is allowed, 0 indicates that merging is not allowed. L = learning bit, if the learning bit is set to 1 this indicates that GELS control plane is used to set up a standard IEEE802.1Q VLAN, i.e. learning, ageing, broadcast and a Multiple Spanning Tree Protocol (MSTP) will be turned on (L=1) or turned of (L=0). bit 0 to 28 are reserved, and has to be set to 0 when sending and ignored when received. 3.4. Suggested Label Object The suggested label object is optional and carried in the PATH message. The format of the suggest label is identical to the format of the Generalized Label object. The information in the Suggested Label in combination with the flags in the LSP_TUNNEL_ETH C-type is interpreted as follows: If the ingress node specifies a VID in the suggested label this is the VID to be used. If the VID field is set to all zeroes, this is an indication that no VID is specified. The DA MAC Address field should always be set to all zeroes by the ingress LSR in a Suggested Label object, and the field SHALL always be ignored when received. Andersson & Gavler Expires July 5, 2007 [Page 9] Internet-Draft A GELS Experiment January 2007 4. Procedures When sending a PATH message the ingress LSR may include a Suggested Label object and/or a Session Atribute Object (C-num = 12). The information in the Suggested Label object and/or Session Attribute Object will be used by the nodes to determine the type of LSP requested. If the ingress LSR does not include a Suggested Label object or a Serssion Attribute object in the PATH message, the egress LSR or merge LSR will treat it as if it were a request for an merge capable LSP with a label consisting of both a VID and a DA MAC address. When an intermediate LSR receives a PATH message with a Suggested Label object and/or a Session Attribute objcet it MUST forward these objects unchanged, unless it is able to merge on to an existing LSP. The criteria for merging is for further study. An egress LSR that receives a path message carrying a Label Request object but no Suggested Label object or any flags in the Session Attribute object WILL interpret this a a request for a merge capable LSP where both the VID and DA MAC Address is used as the label. Note: This section may be extended. Andersson & Gavler Expires July 5, 2007 [Page 10] Internet-Draft A GELS Experiment January 2007 5. Security Considerations This document specify protocol extensions to RSVP-TE that is intended to be used in research contexts. Security consideration has therefore been left for further study and it is strongly recommended not to use these extensions in any network that is part of or connected to the Internet. Andersson & Gavler Expires July 5, 2007 [Page 11] Internet-Draft A GELS Experiment January 2007 6. IANA Considerations We will ask IANA to allocate C-type 12 for LSP_TUNNEL_ETH under the Session Attribute Class 207 Andersson & Gavler Expires July 5, 2007 [Page 12] Internet-Draft A GELS Experiment January 2007 7. Acknowledgements - Andersson & Gavler Expires July 5, 2007 [Page 13] Internet-Draft A GELS Experiment January 2007 8. 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. Andersson & Gavler Expires July 5, 2007 [Page 14] Internet-Draft A GELS Experiment January 2007 Authors' Addresses Loa Andersson Acreo AB Email: loa@pi.se Anders Gavler Acreo AB Email: anders.gavler@acreo.se Andersson & Gavler Expires July 5, 2007 [Page 15] Internet-Draft A GELS Experiment January 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF 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 this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR 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 this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Andersson & Gavler Expires July 5, 2007 [Page 16]