idnits 2.17.1 draft-andersson-gels-exp-rsvp-te-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 411. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 429. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 435. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2007) is 6311 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Andersson 3 Internet-Draft A. Gavler 4 Intended status: Experimental Acreo AB 5 Expires: July 5, 2007 January 2007 7 Extenstion to RSVP-TE for GMPLS Controlled Ethernet - An experimental 8 approach 9 draft-andersson-gels-exp-rsvp-te-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 5, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document specifies the extensions to RSVP-TE that Acreo AB has 43 used in the GMPLS part of testbed. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. GMPLS Controlled Ethernet research . . . . . . . . . . . . . . 4 49 2.1. The Acreo National Broadband Testbed . . . . . . . . . . . 4 50 2.2. Ethernet Control Plane . . . . . . . . . . . . . . . . . . 4 51 2.3. The Ethernet data plane . . . . . . . . . . . . . . . . . 4 52 2.4. Motivation for a GMPLS controlled Ethernet . . . . . . . . 5 53 2.5. Incremental development . . . . . . . . . . . . . . . . . 5 54 3. Protocol extensions . . . . . . . . . . . . . . . . . . . . . 7 55 3.1. Information in the Generalized Label Request Object . . . 7 56 3.2. Label Definition . . . . . . . . . . . . . . . . . . . . . 7 57 3.3. Extensions to the Session Attribute Object . . . . . . . . 8 58 3.4. Suggested Label Object . . . . . . . . . . . . . . . . . . 9 59 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 65 Intellectual Property and Copyright Statements . . . . . . . . . . 16 67 1. Introduction 69 This Internet Draft documents the extensions to RSVP-TE that were 70 used in the tests of GMPLS Controlled Ethernet (GELS), which were 71 performed in the Acreo National Broadband Testbed end of 2006 and 72 early 2007. 74 In Section 2 we give a short background of the research in the test 75 bed in general and the GMPLS controlled Ethernet in particular. 77 Note: The -01 draft has been updated after comments on the gels 78 mailing list, and does when it is written not exactly match our 79 implementation. 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC-2119 [RFC2119]. 85 2. GMPLS Controlled Ethernet research 87 2.1. The Acreo National Broadband Testbed 89 The Acreo National Broadband Testbed (ANBT) has been set up a joint 90 effort by the Swedish government and the Swedish industry. Acreo AB 91 was chosen to host the test bed, and the task is to initiate research 92 projects on different aspects of broadband networks. Methods for 93 control of carrier Ethernet has attracted quite a bit of interest. 95 GELS test bed is subset of the ABNT and consists of a 6 GMPLS enabled 96 IP routers and 4 Ethernet Bridges. In some of our tests we've also 97 used Linux based SW Ethernet Bridges. 99 2.2. Ethernet Control Plane 101 The control plane as implemented in the ANBT consists of three 102 different parts: 104 o Routing Protocol - OSPF-TE, we are running the OSPF-TE exactly as 105 implemented by the Dragon project. 107 o Signaling protocol - RSVP-TE, we have made the extensions to 108 RSVP-TE, RFC3471 [RFC3471] and RFC3473 [RFC3473] as specified in 109 Section 3. 111 o Link Management Protocol - LMP, we have not yet implemented the 112 LMP protocol. 114 2.3. The Ethernet data plane 116 In the test bed we have used the Ethernet data plane as specified in 117 IEEE Std 802.1Q. This has been made possible since we control the 118 entire network by a GMPLS control plane and by default set up loop 119 free LSPs. We have no traffic entering the network that results in 120 that flooding or learning is triggered. This is clearly an 121 artificial condition, but it is very well acceptable in a research 122 network. 124 To take GELS into production networks is outside the scope of the 125 current work we've undertaken, our focus is to establish a test bed 126 e.g. for tests of new control plane extensions, traffic engineering 127 paradigms and advanced applications. To run a GMPLS control plane 128 for a production network will quite possibly require 802.1Q S-VLAN 129 tags as specified in the IEEE Std 802.1ad Provider Bridging amendment 130 to IEEE Std 802.1Q. and possibly the future IEEE802.1ah standard. 132 2.4. Motivation for a GMPLS controlled Ethernet 134 The answer to question "Why GELS?" is simple from a research 135 perspective. Very much of research starts from the question "What 136 happens if ...?" 138 In this case the question was "What happens if we make use of an 139 GMPLS control plane to control an Ethernet network?" The answer to 140 that question will decide whether we'll continue using GELS a as 141 configuration tool while setting up tests in our network. Two 142 tentative results today is that (1) for the application we have it is 143 working well and saves us time, and (2) that we will look into the 144 possibility to control every dynamic or configurable technology by 145 the GMPLS control plane. 147 In addition to this we also have a number of external parties 148 interested in GELS. 150 We have not been the only party active in this area, we have had a 151 number of communications with e.g. Dave Allan, Don Fedyk, Dimitri 152 Papadimitriou, Adrian Farrel, Attila Takacs, Deborah Brungard, Jai 153 Hyung Cho and Nurit Sprecher. They have not reviewed this document, 154 but nevertheless have had influence on our thinking on the subject. 155 This is the major reason to share what we've been doing. 157 We are also in debt to the Dragon project, that gave us a good start 158 when we could use their open source code as a starting point. 160 2.5. Incremental development 162 Our general approach to GELS has been stable over time, we've wanted 163 to use the possibility to statically configure Ethernet Bridges by 164 means of a GMPLS signalling protocol and to learn network topology 165 and traffic engineering information by means of OSPF-TE. 167 One thing has been changing though; our understanding what the 168 "Ethernet label" is and how it can be used. 170 o Our first approach was that it would be possible to define a new 171 Tag Protocol Identifier (tpid) that should have pointed to 172 "Ethernet Label" rather than a 802.1Q VLAN tag. Since this idea 173 involved major changes to the Ethernet data plane, the Ethernet 174 Standards and existing implementations this idea were quickly 175 dropped. However we were able to prove that the concept works on 176 off the shelf equipment. 178 o Our second approach was to simply use the 802.1Q VLAN tag, but due 179 to scalability problems (4096 labels per network) we wanted to 180 swap them per link. The IEEE802.1 have made it very clear this 181 also breaks existing IEEE standards. However, communications from 182 IEEE802.1 have opened up for a certain type of VID swapping. 183 There are indication that the idea of VID swapping, which is 184 accepted at certain types of interface, might be increasingly 185 accepted in the future. 187 o At this point a number of ideas started to emerge from a lot of 188 different sources. Today we are convinced that an Ethernet tag 189 should be possible to use as an Ethernet label, often in 190 combination with the destination MAC Address. Further we are 191 mostly looking to 802.1Q S-VLAN tags as defined in IEEE Std 192 802.1ad Provider Bridging amendment to IEEE Std 802.1Q. It is 193 possible that when the IEEE Std 802.1ah is ready the new tag 194 defined there will be possible to use. 196 o Our current network works with standard 802.1Q bridges. 198 3. Protocol extensions 200 Taking a starting point in RFC3471 [RFC3471] and RFC3473 [RFC3473] we 201 have made the following extensions and adaptations to RSVP-TE. 203 3.1. Information in the Generalized Label Request Object 205 The required information to be carried by a PATH message in the Label 206 Request Object is defined in RFC3471, and the format of the Label 207 Request Object is defined in RFC3473 as follows: 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Length | Class-Num (19)| C-Type (4) | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | LSP Enc. Type |Switching Type | G-PID | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 For the purpose of GELS we use the following encoding of the Label 218 Request Object: 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Length | Class-Num (19)| C-Type (4) | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Ethernet (2) | L2SC(51) | G-PID (0) | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 This is according to the parameter definitions in RFC3471. 230 3.2. Label Definition 232 The format of a Generalized Label object is: 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Length | Class-Num (16)| C-Type (2) | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Label | 240 | ... | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 We have defined the Ethernet Label object as follows: 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Length | Class-Num (16)| C-Type (2) | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | resv | VID (12) | DA MAC ADDRESS (16/48) | 251 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | DA MAC ADDRESS (32/48) | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 The four most significant bits of the Label field is not used and 256 should be set to 0 went sent and ignored when received. 258 3.3. Extensions to the Session Attribute Object 260 The Session Attribute Object is optional and carried in the PATH 261 message. 263 In RFC3209 [RFC3209] the Session Attribute Object is defined. The 264 Session Attribute Class is 207. RFC3209 also defines two C_Types, 265 LSP_TUNNEL, C-Type = 7 and LSP_TUNNEL_RA, C-Type = 1. 267 The LSP_TUNNEL_RA C-Type includes all the same fields as the 268 LSP_TUNNEL C-Type. Additionally it carries resource affinity 269 information. This document defines a third format LSP_TUNNEL_ETH, 270 the C-type = 12. The LSP_TUNNEL_ETH C-type carries all the same 271 fields as the LSP_TUNNEL_RA C-type. Additionally it carries Ethernet 272 LSP attribute information. 274 We have defined the LSP_TUNNEL_ETH C-type as follows. The Session 275 Attribute Class is 207 and the LSP_TUNNEL_ETH, the C-type is 12. 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Ethernet Flags |T|M|L| 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Exclude-any | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Include-any | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Include-all | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Setup Prio | Holding Prio | Flags | Name Length | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | | 291 // Session Name (NULL padded display string) // 292 | | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 T = type bit, 1 indicates that both VID and DA MAC address is 296 used, 0 indicates that only VID is used. 298 M = merge bit, 1 indicates that merging is allowed, 0 indicates 299 that merging is not allowed. 301 L = learning bit, if the learning bit is set to 1 this indicates 302 that GELS control plane is used to set up a standard IEEE802.1Q 303 VLAN, i.e. learning, ageing, broadcast and a Multiple Spanning 304 Tree Protocol (MSTP) will be turned on (L=1) or turned of (L=0). 306 bit 0 to 28 are reserved, and has to be set to 0 when sending and 307 ignored when received. 309 3.4. Suggested Label Object 311 The suggested label object is optional and carried in the PATH 312 message. The format of the suggest label is identical to the format 313 of the Generalized Label object. 315 The information in the Suggested Label in combination with the flags 316 in the LSP_TUNNEL_ETH C-type is interpreted as follows: 318 If the ingress node specifies a VID in the suggested label this is 319 the VID to be used. If the VID field is set to all zeroes, this 320 is an indication that no VID is specified. 322 The DA MAC Address field should always be set to all zeroes by the 323 ingress LSR in a Suggested Label object, and the field SHALL 324 always be ignored when received. 326 4. Procedures 328 When sending a PATH message the ingress LSR may include a Suggested 329 Label object and/or a Session Atribute Object (C-num = 12). The 330 information in the Suggested Label object and/or Session Attribute 331 Object will be used by the nodes to determine the type of LSP 332 requested. 334 If the ingress LSR does not include a Suggested Label object or a 335 Serssion Attribute object in the PATH message, the egress LSR or 336 merge LSR will treat it as if it were a request for an merge capable 337 LSP with a label consisting of both a VID and a DA MAC address. 339 When an intermediate LSR receives a PATH message with a Suggested 340 Label object and/or a Session Attribute objcet it MUST forward these 341 objects unchanged, unless it is able to merge on to an existing LSP. 342 The criteria for merging is for further study. 344 An egress LSR that receives a path message carrying a Label Request 345 object but no Suggested Label object or any flags in the Session 346 Attribute object WILL interpret this a a request for a merge capable 347 LSP where both the VID and DA MAC Address is used as the label. 349 Note: This section may be extended. 351 5. Security Considerations 353 This document specify protocol extensions to RSVP-TE that is intended 354 to be used in research contexts. Security consideration has 355 therefore been left for further study and it is strongly recommended 356 not to use these extensions in any network that is part of or 357 connected to the Internet. 359 6. IANA Considerations 361 We will ask IANA to allocate C-type 12 for LSP_TUNNEL_ETH under the 362 Session Attribute Class 207 364 7. Acknowledgements 366 - 368 8. References 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, March 1997. 373 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 374 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 375 Tunnels", RFC 3209, December 2001. 377 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 378 (GMPLS) Signaling Functional Description", RFC 3471, 379 January 2003. 381 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 382 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 383 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 385 Authors' Addresses 387 Loa Andersson 388 Acreo AB 390 Email: loa@pi.se 392 Anders Gavler 393 Acreo AB 395 Email: anders.gavler@acreo.se 397 Full Copyright Statement 399 Copyright (C) The IETF Trust (2007). 401 This document is subject to the rights, licenses and restrictions 402 contained in BCP 78, and except as set forth therein, the authors 403 retain all their rights. 405 This document and the information contained herein are provided on an 406 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 407 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 408 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 409 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 410 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 411 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 413 Intellectual Property 415 The IETF takes no position regarding the validity or scope of any 416 Intellectual Property Rights or other rights that might be claimed to 417 pertain to the implementation or use of the technology described in 418 this document or the extent to which any license under such rights 419 might or might not be available; nor does it represent that it has 420 made any independent effort to identify any such rights. Information 421 on the procedures with respect to rights in RFC documents can be 422 found in BCP 78 and BCP 79. 424 Copies of IPR disclosures made to the IETF Secretariat and any 425 assurances of licenses to be made available, or the result of an 426 attempt made to obtain a general license or permission for the use of 427 such proprietary rights by implementers or users of this 428 specification can be obtained from the IETF on-line IPR repository at 429 http://www.ietf.org/ipr. 431 The IETF invites any interested party to bring to its attention any 432 copyrights, patents or patent applications, or other proprietary 433 rights that may cover technology that may be required to implement 434 this standard. Please address the information to the IETF at 435 ietf-ipr@ietf.org. 437 Acknowledgment 439 Funding for the RFC Editor function is provided by the IETF 440 Administrative Support Activity (IASA).