idnits 2.17.1 draft-eastlake-trill-802-protocols-00.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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 534. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 543. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 550. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 556. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (February 2007) is 6272 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Donald Eastlake 3rd 2 INTERNET-DRAFT Motorola 3 Expires: August 2007 February 2007 5 Interaction of RBridges and 802 Protocols 6 ----------- -- -------- --- --- --------- 7 9 Status of This Document 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Distribution of this document is unlimited. Comments should be sent 17 to the TRILL working group mailing list. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Abstract 37 This is a working document discussing the relationship of RBridges, 38 that is, devices implementing the protocol being developed by the 39 IETF TRILL working group, and various IEEE 802.1 amd 802.3 protocols. 41 Table of Contents 43 Status of This Document....................................1 44 Abstract...................................................1 46 Table of Contents..........................................2 48 1. Introduction............................................3 49 1.1 802 Document Designation Conventions...................3 50 1.2 IEEE 802 Standards Prcoess.............................3 52 2. IEEE 802.1 Protocols....................................6 53 2.1 802.1D MAC Bridges.....................................6 54 2.2 802.1Q Virtual Bridged Local Area Networks.............6 55 2.2.1 802.1ad Provder Bridges..............................6 56 2.2.2 802.1ag Connectivity Fault Management................7 57 2.2.3 802.1ah Provder Backbone Bridges.....................7 58 2.2.5 802.1au Congestion Management........................7 59 2.3 802.1X Port Based Network Access Control...............8 60 2.3.1 802.1af Authenticated Key Agreeement.................8 61 2.4 802.1AB Connectivity Discovery.........................8 62 2.5 802.1AE MAC Security...................................9 64 3. IEEE 802.3 Protocols...................................10 65 3.1 802.3as...............................................10 67 4. Multicast Addresses....................................12 69 5. IANA Considerations....................................13 70 6. Security Considerations................................13 71 7. References.............................................13 72 7.1 Normative References..................................13 73 7.2 Informative References................................13 75 Copyright, Disclaimer, and Additional IPR Provisions......15 77 Author's Address..........................................16 78 Expiration and File Name..................................16 80 1. Introduction 82 The IETF TRILL Working Group is developing the protocol for RBridges. 83 RBridges are somewhere between being routers and being bridges. 84 Simplifying a lot, RBridges are like Bridges in that they act 85 transparently, form a broadcast domain, and forward primarily based 86 on layer 2 MAC addresses. But they are like routers in that they swap 87 the outer MAC addresses on each RBridge hop, incorporate a hop count, 88 use a link state algorithm traditionally associated with routing, and 89 deal with some layer 3 issues such as optimizing IP multicast and 90 ARP/ND. 92 The purpose of this document is to briefly survey the relationship of 93 RBridges to some of the myriad 802.1 and 802.3 standards, amendments 94 to those stardards, and work in progress to amend those standards 95 which might be relevant. In its present form, it is only intended for 96 interal use in the TRILL Working Group. However, it is possible that 97 some material in this document could end up being appended to the 98 RBridges protocol specification and/or some later version of this 99 document might be published as an informational RFC. 101 Comments and suggests for improvement are welcome 103 1.1 802 Document Designation Conventions 105 IEEE 802 document designations ending with an upper case letter or 106 letters, such as 802.1D, are stand alone standards. Those ending with 107 a lower case letter or letters, such ad 802.1ad, are admendments 108 which are intended to be incorporated into a later rollup of the base 109 standard document they amend. If a hyphen and a year are appended to 110 a document, such as 802.1D-2004, it indicates an adopted standard 111 whose final approval occured in the year given. 113 1.2 IEEE 802 Standards Prcoess 115 Below is a high level description of the IEEE 802 standards process 116 intended to make comments on the standards status of particular 802 117 efforts more understandable from an IETF perspective. Some details 118 and possible branches are omitted. 120 The first official stage is when a PAR and 5 Criterion document are 121 drafted and approved by an 802 working group, such as 802.1. A PAR, 122 or Project Authorization Request, is similar to a Charter and the 5 123 Criterion is a document justifying the need for and reasonableness of 124 expecting success for the effort. In some cases a Study Group, 125 somewhat akin to a BoF, is formed to explore the topic and draft the 126 PAR and 5 Criterion if the Study Group believes an effort should be 127 chartered. 129 These documents must then be approved by the 802 Executive Committee. 131 After that the PAR only goes up to the New Standards Committee 132 (NESCOM) of the IEEE Standards Board and after NESCOM approval the 133 PAR must finally be approved by the entire Standards Board (which 134 normally meets the day after NESCOM meetings). 136 With an approved PAR, similar to an approved working group Charter in 137 the IETF, the 802 working group holding the PAR can proceed with the 138 work itself but, in 802.1 and 802.3, it usually creates a subsidiary 139 Task Group for the PAR or assignes it to an existing Task Group such 140 as the Interworking Task Group in 802.1 that handles bridging. 142 The body working on the PAR comes up with a Draft, initially version 143 0.01, perhaps equivalent to a -00 protocol draft in the IETF. It 144 ususally continues to work on the this Draft through multiple 145 resivions (0.02, 0.03, ...) until it believes it is ready for Working 146 Group Letter Ballot at which point the latest draft is re-numbered 147 1.0. 149 A Letter Ballot is its own process which involves the members of the 150 ballot pool submitting yes, no, or abstain votes. At least 50% of 151 the pool must vote yes or no and 75% of those voting yes or no must 152 vote yes to pass Letter Ballot. Votes can be accompanied by comments 153 and all valid no votes must be accompanied by comments including a 154 description of what change would satisfy the commenter. 156 If a Draft fails Letter Ballot, the group works on it some more until 157 it again thinks it is ready and then reballots it with the next 158 highest integer version number. Thus, if you see, say, as draft D3.5 159 you know it has gone through 3 Letter Ballots, the most recent on 160 D3.0, and been modified 5 times since that Letter Ballot, but you 161 don't know if it passed any of these Letter Ballots. 163 But getting 75% in a letter ballot is not the end of the story. All 164 comments that were submitted with no votes then must be resolved 165 (rejected, accepted, or accepted but with a counter proposal for a 166 satisfying change in the draft) by a 3/4 vote. And when all comments 167 have been resolved, the draft is "recirculated" to the same voting 168 pool. This iterates until certain criterion are met and working group 169 votes to advance to the next step. This does not usually occur until 170 recirculation approval is over 95%. 172 After getting through Working Group Letter Ballot, the draft then 173 advances to "Sponsor" Letter Ballot where the balloting pool is a 174 group selected by the IEEE to balance the constituencies of interest 175 in the standard. The whole Letter Ballot process then repeats for 176 this new pool, although the draft numbers don't reset but just keep 177 going up. 179 Finally, when the standard meets sufficinet criteria in Sponsor 180 Letter Ballot, it is forwarded for approval to the Standards Revision 181 Committee (REVCOM) of the Standards Board and then to the whole 182 Standards Board. 184 2. IEEE 802.1 Protocols 186 802.1 stand alone protocols are listed as second level headings below 187 and amendments to those standards appear as third level headings. in 188 each case, they are ordered by standards labeling order (A to Z then 189 AA, AB, ...). 191 Note: 802-2001 ("IEEE Standard for Local and Metropolitan Area 192 Networks: Overview and Architecture") and its two adopted amendments, 193 802a-2003 and 802b-2004, define the basic 48 bit address formats, 194 OUIs (oprganizationally unique identifiers), Ethertypes, and similar 195 basic arichtectural quantities and formats. 197 2.1 802.1D MAC Bridges 199 - "IEEE Standard for Local and metropolitan area networks / Media 200 Access Control (MAC) Bridges" 202 802.1D-2004 is the basic 802 bridging description and includes 203 spanning tree. The Rbridges charter implies that unconfigured (plug- 204 and-play) Rbridges provide essentially the same service and that for 205 almost all purposes, a network can be converted from 802.1D bridges 206 to Rbridges by incremental replacement. 208 Of necessity, 802.1D must be fully accounted for in the specification 209 of Rbridges. 211 2.2 802.1Q Virtual Bridged Local Area Networks 213 - "IEEE Standard for Local and metropolitan area networks / Virtual 214 Bridged Local Area Networks" 216 VLANs are added to bridging by 802.1Q-2005. VLAN support is included 217 in RBridges. 219 2.2.1 802.1ad Provder Bridges 221 - "IEEE Standard for Local and metropolitan area networks / Virtual 222 Bridged Local Area Networks / Amendment 4: Provider Bridges" 223 amendment to 802.1Q 225 To support arbitrary VLANs in a bridged service provider cloud which 226 is providing paths between arbitrary customer clouds, 802.1ad 227 provides for provider VLAN tags that have the identical structure to 228 customer VLAN tags but a different Ethertype. Presumably the 229 different Ethertype is for robustness or error detection in case of 230 misconfiguration or the like. 232 This is aimed at solving a problem which is not currently being 233 considered in the RBridge specification. 235 2.2.2 802.1ag Connectivity Fault Management 237 - "Draft Standard for Local and Metropolitan Area Networks / Virtual 238 Bridged Local Area Networks / Amendment 5: Connectivity Fault 239 Management" amendment to 802.1Q 241 TBD 243 2.2.3 802.1ah Provder Backbone Bridges 245 - "Draft Standard for Local and Metropolitan Area Networks / Virtual 246 Bridged Local Area Networks / Amendment 6: Provider Backbone Bridges" 247 amendment to 802.1Q 249 The problem with expanding to a two level system with customer and 250 provider bridges just using 802.1ad is presumably that the provider 251 bridges see too many different customer MAC addresses. 802.1ah 252 encapsulates the ultimate MAC addresses so the provider backbone 253 bridges only see the MAC addresses of the devices at the border 254 between the customer clouds and the provider cloud. 256 This is aimed at solving provider services problems which are not 257 currently being considered in the RBridge specification. 259 2.2.5 802.1au Congestion Management 261 - "Draft Standard for Local and Metropolitan Area Networks / Virtual 262 Bridged Local Area Networks / Amendment 7: Congestion Management" 263 amendment to 802.1Q 265 The 802.1au draft is in a very early stange (version D0.01, 266 equivalent to an IETF -00 draft). 268 Congestion Management (BCN, "Backward Congestion Notification") is a 269 method of reducing or elminating dropped frames within a subnet of 270 bounded delay bandwidth product. The idea is that 802.1au aware 271 devices which experience congestion based on frame queues backing up 272 send messages back to frame sources, generally identified by MAC 273 addresses and within MAC address by flow, specifying the maximum rate 274 at which that source should trasmit frames. Future frames, from that 275 source, which are tagged to indicate that they conform to such a rate 276 limit are given higher priority. 278 Bridges have to be congestion aware to support BCN and so would 279 Rbridges. This has been discussed on the TRILL working group mailing 280 list and at TRILL meetings. 282 2.3 802.1X Port Based Network Access Control 284 - "IEEE Standard for Local and metropolitan area networks / Virtual 285 Bridged Local Area Networks / Amendment 4: Provider Bridges" 287 IEEE 802.1X-2004 is a standard for authenticating devices before 288 permitting access. It is logically unrelated to bridging but is 289 listed here because the 802.1af amendment to 802.1X is relevant to 290 802.1AE. 292 2.3.1 802.1af Authenticated Key Agreeement 294 - "Draft Standard for Local and Metropolitan Area NetworksPort-Based 295 Network Access Control / Amendment 1: Authenticated Key Agreement for 296 Media Access Control (MAC) Security" amendment to 802.1X 298 The 802.1af (sometimes called MacKey) amendment to 802.1X extends it 299 to provided keying for use by 802.1AE (see section 2.5 below). 301 2.4 802.1AB Connectivity Discovery 303 - "IEEE Standard for Local and metropolitan area networks / Station 304 and Media Access Control / Connectivity Discovery" 306 This standard specifies frames that can be emitted by devices to 307 announce themselves to other devices on the same link. Possibly the 308 RBridge specifciation could contain advance as to the 802.1AB 309 announcements sent by RBridges which choose emit such announcements. 311 2.5 802.1AE MAC Security 313 - "IEEE Standard for Local and metropolitan area networks / Media 314 Access Control (MAC) Security" 316 802.1AE-2006 (sometimes called MacSec) is a completed standard but 317 has no provisions for keying. One set of such provisions is in 318 802.1af which, as described above in section 2.3.1, is under 319 development as an amendment to 802.1X. 321 With one exception, 802.1AE simply provides security over one hop 322 between 802.1AE conformant points of attachment. As such, 802.1AE 323 seems equially applicable to such points of attachment on bridges, 324 routers, Rbridges, and end equipment such as non-routing hosts. 326 This exception being where a pieced of customer equipment is 327 connected to provider backbone equipement as described in 802.1ah. 329 It is not clear how successful 802.1AE will be. The various wireless 330 protocols under 802 (802.11 (Wi-Fi), 802.15.1 (Blue Tooth), 802.15.4 331 (ZigBee), 802.16 (WiMax), etc.) have all adopted their own security 332 protocols. In the wired world, connections are increasingly point-to- 333 point and for such links you would want security closer to the 334 physical layer so as to provide protection against taffic analysis 335 and avoid leaving the frame structure/size, MAC addresses, etc., 336 visible as plain text the way 802.1AE does. Note that there was a 337 previous general 802 link security protocol, 802.10, which received 338 little deployment and has been withdrawn. 340 3. IEEE 802.3 Protocols 342 - "IEEE Standard for Information technology / Telecommunications and 343 information exchange between systems / Local and metropolitan area 344 networks / Specific requirements / Part 3: Carrier sense multiple 345 access with collision detection (CSMA/CD) access method and physical 346 layer specifications" 348 802.3-2005 is a completed link standard. The ideas in Rbridges can 349 be applied to a variety of link protocols so, for the most part, the 350 Rbridge architecture is link independent. Nevertheless, it is first 351 being specified for 802.3. 353 802.3-2005 Clause 31 "MAC Control" defines a low level facility for 354 control on 802.3 links. Subclause 31.4 "MAC Control Frames" gives 355 some further format details while Annex 31A "MAC Control opcode 356 assignments" lists the current opcodes available. There are actually 357 six but the only one I had ever heard of before looking into this 358 document was opcode 1, PAUSE, which is further explaine in Annex 31B 359 "MAC Control PAUSE operation". 361 I expect that PAUSE will eventually be deprecated in most 362 circumstances because 802.1au, Congestion Notification, is superior. 364 3.1 802.3as 366 - IEEE Standard for Information technology / Telecommunications and 367 information exchange between systems / Local and metropolitan area 368 networks / Specific requirements / Part 3: Carrier sense multiple 369 access with collision detection (CSMA/CD) access method and physical 370 layer specifications / Amendment: Frame format extensions" amendment 371 to 802.3 373 You may have been wondering why no one seems particularly worried 374 about exceeding MTUs when frames are lengthened by the RBridge 375 encapsulation. In fact, 802.3 and similar hardware has long been able 376 to handle frames that were longer than those specified in the 377 standards to accomodate such things. 379 Apparently, when Ethernet was first specified, the idea was that data 380 would be limited to 1024 bytes and the maximum frame size was set to 381 1500 to leave lots of room for things like headers and encapsulation. 382 But vendors crammed in as much data as they could so that, when Q- 383 tags (VLAN) were added, even though it was only 4 more bytes, it was 384 thought necessary to define a higher limit for Q-tagged frames. Now 385 that lots of things are considering additional tags, such as security 386 tags with 802.1AE, BCN related tags with 802.1au, provider things 387 like 802.1ad and 802.1ah, and RBridges, a further extension has been 388 defined along with more stringent words saying not to use up the 389 extra space with data. 391 The current 802.3as draft defines three frame types for conformance 392 purposes: 394 1500 octets - basic frames 395 1504 octets - Q-tagged frames 396 1982 octets - envelope frames 398 4. Multicast Addresses 400 A block of 16 multicast MAC addresses is reserved for use by 401 802.1/802.3 protocols (officially 802.1 and media specific 402 protocols). These are in the range from 0180C2000000 to 0180C200000F 403 in hexadecimal. 405 The general behavior of bridges is to flood multicast on a spanning 406 tree so that multicast frames reach all stations. However, for 407 multicast addresses in this block, the general behaviour of bridges, 408 routers, etc., is specified as discarding the frame unless they "know 409 what to do with it". This usually involves processing the contents of 410 the frame and that processing may cause frames, including frames 411 addressed to the same multicast destination MAC address, to be 412 originated by the device. 414 The current uses or anticipated future uses for these addresses are 415 shown below: 417 0180C2000000 - All Bridges: Used for BPDUs. Must be recongized by 418 RBridges due to RBridge port participation in spanning tree as 419 a leaf. 421 0180C2000001 - 802.3 Clause 31 use, i.e. Full Duplex PAUSE 422 operation 424 0180C2000002 - 802.3 Clause 43 (Link Aggregation) and Clause 57 425 (OAM) use, aka "Slow Protocols" Multicast address 427 0180C2000003 - 802.1X Port Authenticator Entity (PAE) address 429 0180C2000004-5 - Reserved for future media access specific method 430 standardization 432 0180C2000006-7 - Reserved for future standardization 434 0180C2000008 - All Provider Bridges 436 0180C2000009-C - Reserved for future standardization 438 0180C200000D - Provider Bridge GVRP Address 440 0180C200000E - 802.1AB Link Layer Discovery Protocol address 442 0180C200000F - Reserved for future standardization 444 5. IANA Considerations 446 None. 448 6. Security Considerations 450 TBD. 452 7. References 454 Many of the completed 802 standards are available for free download 455 through the "Get 802" program. See 456 http://standards.ieee.org/getieee802/. 458 7.1 Normative References 460 None? 462 7.2 Informative References 464 [802.1] "IEEE Standard for Local and Metropolitan Area Networks: 465 Overview and Architecture", IEEE 802-2001, 8 March 2002. 467 [802.1D] "IEEE Standard for Local and metropolitan area networks / 468 Media Access Control (MAC) Bridges", 802.1D-2004, 9 June 2004. 470 [802.1Q] "IEEE Standard for Local and metropolitan area networks / 471 Virtual Bridged Local Area Networks", 802.1Q-2005, 19 May 2006. 473 [802.1X] "IEEE Standard for Local and metropolitan area networks / 474 Virtual Bridged Local Area Networks", 802.1X-2004, 13 December 2004. 476 [802.1AB] "IEEE Standard for Local and metropolitan area networks / 477 Station and Media Access Control Connectivity Discovery", 478 802.1AB-2005, 6 May 2005. 480 [802.1ad] "IEEE Standard for Local and metropolitan area networks / 481 Virtual Bridged Local Area Networks / Amendment 4: Provider Bridges", 482 802.1ad-2005 (amendment to 802.1Q), 26 May 1006. 484 [802.1AE] "IEEE Standard for Local and metropolitan area networks / 485 Media Access Control (MAC) Security", 802.1AE-2006, 18 August 2006. 487 [802.1af] "Draft Standard for Local and Metropolitan Area 488 NetworksPort-Based Network Access Control / Amendment 1: 489 Authenticated Key Agreement for Media Access Control (MAC) Security", 490 Draft D1.2, 20 January 2007. 492 [802.1ag] "Draft Standard for Local and Metropolitan Area Networks / 493 Virtual Bridged Local Area Networks / Amendment 5: Connectivity Fault 494 Management", Draft D7.1, 7 November 2006. 496 [802.1ah] "Draft Standard for Local and Metropolitan Area Networks / 497 Virtual Bridged Local Area Networks / Amendment 6: Provider Backbone 498 Bridges", Draft D3.3, 13 December 2006. 500 [802.1ak] "Draft Standard for Local and Metropolitan Area Networks / 501 Virtual Bridged Local Area Networks / Amendment 07: Multiple 502 Registration Protocol", Draft D6.0, 10 June 2006. 504 [802.1au] "Draft Standard for Local and Metropolitan Area Networks / 505 Virtual Bridged Local Area Networks / Amendment 7: Congestion 506 Management", Draft D0.01, 29 September 2006. 508 [802.3] "IEEE Standard for Information technology / 509 Telecommunications and information exchange between systems / Local 510 and metropolitan area networks / Specific requirements / Part 3: 511 Carrier sense multiple access with collision detection (CSMA/CD) 512 access method and physical layer specifications", 802.3-2005, 9 513 December 2005. 515 [802.3as] "Draft Amendment of IEEE Standard for Information 516 technology / Telecommunications and information exchange between 517 systems / Local and metropolitan area networks / Specific 518 requirements / Part 3: Carrier sense multiple access with collision 519 detection (CSMA/CD) access method and physical layer specifications / 520 Amendment: Frame format extensions", Draft D3.1, 24 April 2006. 522 Copyright, Disclaimer, and Additional IPR Provisions 524 Copyright (C) The IETF Trust (2007). This document is subject to the 525 rights, licenses and restrictions contained in BCP 78, and except as 526 set forth therein, the authors retain all their rights. 528 This document and the information contained herein are provided on an 529 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 530 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 531 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 532 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 533 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 534 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 536 The IETF takes no position regarding the validity or scope of any 537 Intellectual Property Rights or other rights that might be claimed to 538 pertain to the implementation or use of the technology described in 539 this document or the extent to which any license under such rights 540 might or might not be available; nor does it represent that it has 541 made any independent effort to identify any such rights. Information 542 on the procedures with respect to rights in RFC documents can be 543 found in BCP 78 and BCP 79. 545 Copies of IPR disclosures made to the IETF Secretariat and any 546 assurances of licenses to be made available, or the result of an 547 attempt made to obtain a general license or permission for the use of 548 such proprietary rights by implementers or users of this 549 specification can be obtained from the IETF on-line IPR repository at 550 http://www.ietf.org/ipr. 552 The IETF invites any interested party to bring to its attention any 553 copyrights, patents or patent applications, or other proprietary 554 rights that may cover technology that may be required to implement 555 this standard. Please address the information to the IETF at ietf- 556 ipr@ietf.org. 558 Author's Address 560 Author's Addresses 562 Donald Eastlake 3rd 563 Motorola Laboratories 564 111 Locke Drive 565 Marlborough, MA 01752 567 Tel: +1-508-786-7554 568 Email: Donald.Eastlake@motorola.com 570 Expiration and File Name 572 This draft expires in August 2007. 574 Its file name is draft-eastlake-trill-802-protocols-00.txt.