Network Working Group L. Andersson Internet-Draft A. Gavler Intended status: Experimental Acreo AB Expires: July 30, 2007 January 26, 2007 Extenstion to RSVP-TE for GMPLS Controlled Ethernet - An experimental approach draft-andersson-gels-exp-rsvp-te-00.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 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Andersson & Gavler Expires July 30, 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. Suggested Label . . . . . . . . . . . . . . . . . . . . . 8 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 30, 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. 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 30, 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 Ethernet as specified in in IEEE Std 802.1Q. This has been possible since we control the entire network by a GMPLS control plane and by default set up loop free LSPs. We have no traffic that results in that flooding or learning is triggered entering the network. 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 30, 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 answere 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 asa 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 30, 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 30, 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 (33) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 30, 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VID (12) | DA MAC ADDRESS (20/48) | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DA MAC ADDRESS (28/48) |T|M|L|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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.1 VLAN, i.e. learning, ageing, broadcast and a Spanning Tree Protocol (STP) will be turned on. R = reserved, set to 0 when sending, ignored when received. 3.3. Suggested Label The suggested label object is optional and carried in the PATH message. The format of the suggest is identical to the format of the Generalized Label object. The information and flags in the Suggested Label 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 0 by the ingress LSR in a Suggested Label object, and the field SHALL always be ignored when received. Andersson & Gavler Expires July 30, 2007 [Page 8]
Internet-Draft A GELS Experiment January 2007 T = type bit, is set to 1 to indicate that both VID and DA MAC address should be used as the label. If the bit it set to 0 this indicates that only the VID should be used as label. M = merge bit, is set to 0 to indicate that merging is not allowed, and to 1 to indicate that it is allowed. L = learning bit, is set to 1 to indicate that the GELS control plane is used to set up a standard IEEE802.1 VLAN. The learning bit is set to 0 to indicate that an Ethernet LSP is requested. R = reserved bit, is always set to 0 when sending, and always ignored when receiving. Andersson & Gavler Expires July 30, 2007 [Page 9]
Internet-Draft A GELS Experiment January 2007 4. Procedures When sending a PATH message the ingress LSR need to include a Suggested Label object. The information in the Suggested Label object will be used by the egress node to determine the type of service requested. If the ingress LSR does not include a Suggested Label 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 it MUST forward the Suggested Label object 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 WILL interpret this a a request for a merge capable LSP where both the VID and DA MAC Address is used a the label. Note: This section may be extended. Andersson & Gavler Expires July 30, 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 30, 2007 [Page 11]
Internet-Draft A GELS Experiment January 2007 6. IANA Considerations There are no requests to the IANA herein. Andersson & Gavler Expires July 30, 2007 [Page 12]
Internet-Draft A GELS Experiment January 2007 7. Acknowledgements - Andersson & Gavler Expires July 30, 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. [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 30, 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 30, 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 30, 2007 [Page 16]