idnits 2.17.1 draft-ietf-pppext-bcp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 37 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 38 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The abstract seems to contain references ([3], [6], [8], [9]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 125: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 126: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 274: '... MUST successfully negotiate the Bri...' RFC 2119 keyword, line 284: '...nto the PPP link MUST update the RIF o...' RFC 2119 keyword, line 422: '...phase is reached SHOULD be silently di...' (49 more instances...) -- The abstract seems to indicate that this document obsoletes RFC1638, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 639 has weird spacing: '...thernet with ...' == Line 813 has weird spacing: '...thernet with ...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the value is 1, IEEE-802-Tagged-Frame is enabled. If the value is 2, IEEE-802-Tagged-Frame is disabled, and MUST not send any IEEE-802-Tagged-Frame packet. -- 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 (April 2000) is 8777 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '6' on line 1609 looks like a reference -- Missing reference section? '3' on line 1599 looks like a reference -- Missing reference section? '8' on line 1615 looks like a reference -- Missing reference section? '9' on line 1623 looks like a reference -- Missing reference section? '2' on line 1596 looks like a reference -- Missing reference section? '12' on line 1633 looks like a reference -- Missing reference section? '1' on line 1593 looks like a reference -- Missing reference section? '7' on line 1612 looks like a reference -- Missing reference section? '11' on line 1630 looks like a reference -- Missing reference section? '10' on line 1627 looks like a reference -- Missing reference section? '4' on line 1602 looks like a reference -- Missing reference section? '5' on line 1606 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPP Working Group M. Higashiyama 2 INTERNET DRAFT Anritsu 3 Expires October 2000 F. Baker 4 Cisco 5 April 2000 7 PPP Bridging Control Protocol (BCP) 8 draft-ietf-pppext-bcp-04.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (1999). All Rights Reserved. 35 Abstract 37 The Point-to-Point Protocol (PPP) [6] provides a standard method for 38 transporting multi-protocol datagrams over point-to-point links. PPP 39 defines an extensible Link Control Protocol, and proposes a family of 40 Network Control Protocols for establishing and configuring different 41 network-layer protocols. 43 This document defines the Network Control Protocol for establishing 44 and configuring Remote Bridging for PPP links. 46 This document obsoletes RFC 1638, which was based on the IEEE 47 802.1D-1993 MAC Bridge[3]. This document extends that specification 48 by including the IEEE 802.1D-1998 MAC Bridge[8] and IEEE 802.1Q 49 Virtual LAN (VLAN)[9] standards. This document also improves the 50 protocol in order to support high-speed switched LANs. 52 Table of Contents 54 1. Historical Perspective ................................ 3 55 1.1 Requirements Keywords ........................... 3 56 2. Methods of Bridging ................................... 3 57 2.1 Transparent Bridging ............................ 3 58 2.2 Remote Transparent Bridging ..................... 4 59 2.3 Source Routing .................................. 5 60 2.4 Remote Source Route Bridging .................... 6 61 2.5 SR-TB Translational Bridging .................... 7 62 3. Traffic Services ...................................... 7 63 3.1 LAN Frame Checksum Preservation ................. 7 64 3.2 Traffic having no LAN Frame Checksum ............ 7 65 3.3 Tinygram Compression ............................ 8 66 3.4 Virtual LANs .................................... 8 67 4. A PPP Network Control Protocol for Bridging ........... 9 68 4.1 Sending Bridge Frames ........................... 10 69 4.1.1 Maximum Receive Unit Considerations ............. 10 70 4.1.2 Loopback and Link Quality Monitoring ............ 11 71 4.1.3 Message Sequence ................................ 11 72 4.1.4 Separation of Spanning Tree Domains ............. 11 73 4.2 Bridged LAN Traffic in IEEE 802 Untagged Frame .. 13 74 4.3 Bridged LAN Traffic in IEEE 802 Tagged Frame .... 17 75 4.4 Bridge management protocol data unit ............ 21 76 5. BCP Configuration Options ............................. 21 77 5.1 Bridge-Identification ........................... 22 78 5.2 Line-Identification ............................. 23 79 5.3 MAC-Support ..................................... 25 80 5.4 Tinygram-Compression ............................ 26 81 5.5 MAC-Address ..................................... 27 82 5.6 Spanning Tree Protocol (old formatted) .......... 28 83 5.7 IEEE-802-Tagged-Frame ........................... 30 84 5.8 Management-Inline ............................... 30 85 6. Change Log ............................................ 31 86 7. Security Considerations ............................... 32 87 8. Intellectual Property Notice .......................... 32 88 9. IANA Considerations ................................... 33 89 10. Acknowledgments ....................................... 33 90 APPENDICES ................................................... 34 91 A. Spanning Tree Bridge PDU (old formatted) ........... 34 92 B. Tinygram-Compression Pseudo-Code ................... 36 93 C. References ......................................... 37 95 AUTHOR'S ADDRESS ............................................. 38 96 Full Copyright Statement...................................... 38 98 1. Historical Perspective 100 Two basic algorithms are ambient in the industry for Bridging of 101 Local Area Networks. The more common algorithm is called 102 "Transparent Bridging", and has been standardized for Extended LAN 103 configurations by IEEE 802.1. The other is called "Source Route 104 Bridging", and is prevalent on IEEE 802.5 Token Ring LANs. 106 The IEEE has combined these two methods into a device called a Source 107 Routing Transparent (SRT) bridge, which concurrently provides both 108 Source Route and Transparent bridging. Transparent and SRT bridges 109 are specified in IEEE standard 802.1D-1998 [8]. 111 Although IEEE committee 802.1G is addressing remote bridging [2], 112 neither standard directly defines the mechanisms for implementing 113 remote bridging. Technically, that would be beyond the IEEE 802 114 committee's charter. However, both 802.1D and 802.1G allow for it. 115 The implementor may model the line either as a component within a 116 single MAC Relay Entity, or as the LAN media between two remote 117 bridges. 119 The original IEEE 802.1D is augmented by IEEE 802.1Q [9] to provide 120 support for Virtual LAN. Virtual LAN is an integral feature of 121 switched LAN networks. 123 1.1 Requirements Keywords 125 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 126 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 127 document, are to be interpreted as described in [12]. 129 2. Methods of Bridging 131 2.1. Transparent Bridging 133 As a favor to the uninitiated, let us first describe Transparent 134 Bridging. Essentially, the bridges in a network operate as isolated 135 entities, largely unaware of each others' presence. A Transparent 136 Bridge maintains a Forwarding Database consisting of 138 {address, interface} 140 or 142 {address, interface, VLAN ID} 144 records, by saving the Source Address of each LAN transmission that 145 it receives, along with the interface identifier for the interface it 146 was received on. Bridges which support Virtual LANs additionally 147 keep the Virtual LAN ID in their forwarding database. It goes on to 148 check whether the Destination Address is in the database, and if so, 149 either discards the message when the destination and source are 150 located at the same interface, or forwards the message to the 151 indicated interface. A message whose Destination Address is not 152 found in the table is forwarded to all interfaces except the one it 153 was received on. This behavior applies to Broadcast/Multicast frames 154 as well. 156 The obvious fly in the ointment is that redundant paths in the 157 network cause indeterminate (nay, all too determinate) forwarding 158 behavior to occur. To prevent this, a protocol called the Spanning 159 Tree Protocol is executed between the bridges to detect and logically 160 remove redundant paths from the network. 162 One system is elected as the "Root", which periodically emits a 163 message called a Bridge Protocol Data Unit (BPDU), heard by all of 164 its neighboring bridges. Each of these modifies and passes the BPDU 165 on to its neighbors, until it arrives at the leaf LAN segments in the 166 network (where it dies, having no further neighbors to pass it 167 along), or until the message is stopped by a bridge which has a 168 superior path to the "Root". In this latter case, the interface the 169 BPDU was received on is ignored (it is placed in a Hot Standby 170 status, no traffic is emitted onto it except the BPDU, and all 171 traffic received from it is discarded), until a topology change 172 forces a recalculation of the network. 174 To establish Virtual LANs in an environment of multiple bridges, GVRP 175 (GARP VLAN Registration Protocol) is executed between bridges to 176 exchange Virtual LAN information. GVRP provides a mechanism to 177 dynamically establish and update their knowledge of the set of 178 Virtual LANs that currently have active members. 180 To reduce unnecessary multicast flooding in the network, bridges 181 exchange group MAC addresses using the GARP Multicast Registration 182 Protocol. GMRP provides a mechanism so that bridges can know which 183 multicast frames should be forwarded on each port. 185 2.2. Remote Transparent Bridging 187 There exist two basic sorts of bridges -- those that interconnect 188 LANs directly, called Local Bridges, and those that interconnect LANs 189 via an intermediate medium such as a leased line, called Remote 190 Bridges. PPP may be used to connect Remote Bridges. 192 The IEEE 802.1G Remote MAC Bridging committee has proposed a model of 193 a Remote Bridge in which a set of two or more Remote Bridges that are 194 interconnected via remote lines are termed a Remote Bridge Group. 195 Within a Group, a Remote Bridge Cluster is dynamically formed through 196 execution of the spanning tree as the set of bridges that may pass 197 frames among each other. 199 This model bestows on the remote lines the basic properties of a LAN, 200 but does not require a one-to-one mapping of lines to virtual LAN 201 segments. For instance, the model of three interconnected Remote 202 Bridges, A, B and C, may be that of a virtual LAN segment between A 203 and B and another between B and C. However, if a line exists between 204 Remote Bridges B and C, a frame could actually be sent directly from 205 B to C, as long as there was the external appearance that it had 206 travelled through A. 208 IEEE 802.1G thus allows for a great deal of implementation freedom 209 for features such as route optimization and load balancing, as long 210 as the model is maintained. 212 For simplicity, we discuss Remote Bridging in this document in terms 213 of two Remote Bridges connected by a single line. 215 2.3. Source Routing 217 The IEEE 802.1D Committee has standardized Source Routing for any MAC 218 Type that allows its use. Currently, MAC Types that support Source 219 Routing are FDDI and IEEE 802.5 Token Ring. 221 The IEEE standard defines Source Routing only as a component of an 222 SRT bridge. However, many bridges have been implemented which are 223 capable of performing Source Routing alone. These are most commonly 224 implemented in accordance either with the IBM Token-Ring Network 225 Architecture Reference [1] or with the Source Routing Appendix of 226 IEEE 802.1D-1998 [8]. 228 In the Source Routing approach, the originating system has the 229 responsibility of indicating the path that the message should follow. 230 It does this, if the message is directed off of the local segment, by 231 including a variable length MAC header extension called the Routing 232 Information Field (RIF). The RIF consists of one 16-bit word of 233 flags and parameters, followed by zero or more segment-and-bridge 234 identifiers. Each bridge en route determines from this source route 235 list whether it should accept the message and how to forward it. 237 In order to discover the path to a destination, the originating 238 system transmits an Explorer frame. An All-Routes Explorer (ARE) 239 frame follows all possible paths to a destination. A Spanning Tree 240 Explorer (STE) frame follows only those paths defined by Bridge ports 241 that the Spanning Tree Algorithm has put in Forwarding state. Port 242 states do not apply to ARE or Specifically-Routed Frames. The 243 destination system replies to each copy of an ARE frame with a 244 Specifically-Routed Frame, and to an STE frame with an ARE frame. In 245 either case, the originating station may receive multiple replies, 246 from which it chooses the route it will use for future Specifically- 247 Routed Frames. 249 The algorithm for Source Routing requires the bridge to be able to 250 identify any interface by its segment-and-bridge identifier. When a 251 packet is received that has the RIF present, a boolean in the RIF is 252 inspected to determine whether the segment-and-bridge identifiers are 253 to be inspected in "forward" or "reverse" sense. In its search, the 254 bridge looks for the segment-and-bridge identifier of the interface 255 the packet was received on, and forwards the packet toward the 256 segment identified in the segment-and-bridge identifier that follows 257 it. 259 GVRP and GMRP are available and effective on Source Routing networks. 261 2.4. Remote Source Route Bridging 263 There is no Remote Source Route Bridge proposal in IEEE 802.1 at this 264 time, although many vendors ship remote Source Routing Bridges. 266 We allow for modelling the line either as a connection residing 267 between two halves of a "split" Bridge (the split-bridge model), or 268 as a LAN segment between two Bridges (the independent-bridge model). 269 In the latter case, the line requires a LAN Segment ID. 271 By default, PPP Source Route Bridges use the independent-bridge 272 model. This requirement ensures interoperability in the absence of 273 option negotiation. In order to use the split-bridge model, a system 274 MUST successfully negotiate the Bridge-Identification Configuration 275 Option. 277 Although no option negotiation is required for a system to use the 278 independent-bridge model, it is strongly recommended that systems 279 using this model negotiate the Line-Identification Configuration 280 Option. Doing so will verify correct configuration of the LAN 281 Segment Id assigned to the line. 283 When two PPP systems use the split-bridge model, the system that 284 transmits an Explorer frame onto the PPP link MUST update the RIF on 285 behalf of the two systems. The purpose of this constraint is to 286 ensure interoperability and to preserve the simplicity of the 287 bridging algorithm. For example, if the receiving system did not 288 know whether the transmitting system had updated the RIF, it would 289 have to scan the RIF and decide whether to update it. The choice of 290 the transmitting system for the role of updating the RIF allows the 291 system receiving the frame from the PPP link to forward the frame 292 without processing the RIF. 294 Given that source routing is configured on a line or set of lines, 295 the specifics of the link state with respect to STE frames are 296 defined by the Spanning Tree Protocol in use. Choice of the split- 297 bridge or independent-bridge model does not affect spanning tree 298 operation. In both cases, the spanning tree protocol is executed on 299 the two systems independently. 301 2.5. SR-TB Translational Bridging 303 IEEE 802 is not currently addressing bridges that translate between 304 Transparent Bridging and Source Routing. For the purposes of this 305 standard, such a device is either a Transparent or a Source Routing 306 bridge, and will act on the line in one of these two ways, just as it 307 does on the LAN. 309 3. Traffic Services 311 Several services are provided for the benefit of different system 312 types and user configurations. These include LAN Frame Checksum 313 Preservation, LAN Frame Checksum Generation, Tinygram Compression, 314 and the identification of closed sets of LANs. 316 3.1. LAN Frame Checksum Preservation 318 IEEE 802.1 stipulates that the Extended LAN must enjoy the same 319 probability of undetected error that an individual LAN enjoys. 320 Although there has been considerable debate concerning the algorithm, 321 no other algorithm has been proposed than having the LAN Frame 322 Checksum received by the ultimate receiver be the same value 323 calculated by the original transmitter. Achieving this requires, of 324 course, that the line protocols preserve the LAN Frame Checksum from 325 end to end. The protocol is optimized towards this approach. 327 3.2. Traffic having no LAN Frame Checksum 329 The fact that the protocol is optimized towards LAN Frame Checksum 330 preservation raises twin questions: "What is the approach to be used 331 by systems which, for whatever reason, cannot easily support Frame 332 Checksum preservation?" and "What is the approach to be used when the 333 system originates a message, which therefore has no Frame Checksum 334 precalculated?". 336 Surely, one approach would be to require stations to calculate the 337 Frame Checksum in software if hardware support were unavailable; this 338 would meet with profound dismay, and would raise serious questions of 339 interpretation in a Bridge/Router. 341 However, stations which implement LAN Frame Checksum preservation 342 must already solve this problem, as they do originate traffic. 343 Therefore, the solution adopted is that messages which have no Frame 344 Checksum are tagged and carried across the line. 346 When a system which does not implement LAN Frame Checksum 347 preservation receives a frame having an embedded FCS, it converts it 348 for its own use by removing the trailing four octets. When any 349 system forwards a frame which contains no embedded FCS to a LAN, it 350 forwards it in a way which causes the FCS to be calculated. 352 3.3. Tinygram Compression 354 An issue in remote Ethernet bridging is that the protocols that are 355 most attractive to bridge are prone to problems on low speed (64 KBPS 356 and below) lines. This can be partially alleviated by observing that 357 the vendors defining these protocols often fill the PDU with octets 358 of ZERO. Thus, an Ethernet or IEEE 802.3 PDU received from a line 359 that is (1) smaller than the minimum PDU size, and (2) has a LAN 360 Frame Checksum present, must be padded by inserting zeroes between 361 the last four octets and the rest of the PDU before transmitting it 362 on a LAN. These protocols are frequently used for interactive 363 sessions, and therefore are frequently this small. 365 To prevent ambiguity, PDUs requiring padding are explicitly tagged. 366 Compression is at the option of the transmitting station, and is 367 probably performed only on low speed lines, perhaps under 368 configuration control. 370 The pseudo-code in Appendix B describes the algorithms. 372 3.4. Virtual LANs 374 IEEE 802.1Q defines Virtual LANs and their exchangeable VLAN Tagged 375 frame format. Virtual LANs allow user multiple community groups to 376 co-exist within one bridge. A bridging community is identified by its 377 VLAN ID. If a system that supports Virtual LANs receives a frame from 378 the LAN, that frame will be only emitted onto a LAN which belongs to 379 the same community. In order to handle multiple communities on a 380 single line, IEEE 802.1Q defines a VLAN Tagged Frame. 382 For example, suppose you have the following configuration: 384 E1 +--+ +--+ E3 385 ------------| | | |------------ 386 | | W1 | | 387 |B1|------------|B2| 388 E2 | | | | E4 389 ------------| | | |------------ 390 +--+ +--+ 392 E1, E2, E3, and E4 are Ethernet LANs (or Token Ring, FDDI, etc.). W1 393 is a WAN (PPP over T1). B1 and B2 are MAC level bridges. 395 You want End Stations on E1 and E3 to communicate, and you want End 396 Stations on E2 and E4 to communicate, but you do not want End 397 Stations on E1 and E3 to communicate with End Stations on E2 and E4. 399 This is true for Unicast, Multicast, and Broadcast traffic. If a 400 broadcast datagram originates on E1, you want it only to be 401 propagated to E3, and not on E2 or E4. 403 Another way of looking at it is that E1 and E3 form a Virtual LAN, 404 and E2 and E4 form a Virtual LAN, as if the following configuration 405 were actually being used: 407 E1 +--+ W2 +--+ E3 408 ------------|B3|------------|B4|------------ 409 +--+ +--+ 411 E2 +--+ W3 +--+ E4 412 ------------|B5|------------|B6|------------ 413 +--+ +--+ 415 4. A PPP Network Control Protocol for Bridging 417 The Bridging Control Protocol (BCP) is responsible for configuring, 418 enabling and disabling the bridge protocol modules on both ends of 419 the point-to-point link. BCP uses the same packet exchange mechanism 420 as the Link Control Protocol. BCP packets may not be exchanged until 421 PPP has reached the Network-Layer Protocol phase. BCP packets 422 received before this phase is reached SHOULD be silently discarded. 424 The Bridging Control Protocol is exactly the same as the Link Control 425 Protocol [6] with the following exceptions: 427 Frame Modifications 428 The packet may utilize any modifications to the basic frame format 429 which have been negotiated during the Link Establishment phase. 431 Implementations SHOULD NOT negotiate Address-and-Control-Field- 432 Compression or Protocol-Field-Compression on other than low speed 433 links. 435 Data Link Layer Protocol Field 437 Exactly one BCP packet is encapsulated in the PPP Information 438 field, where the PPP Protocol field indicates type hex 8031 (BCP). 440 Code field 442 Only Codes 1 through 7 (Configure-Request, Configure-Ack, 443 Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack 444 and Code-Reject) are used. Other Codes SHOULD be treated as 445 unrecognized and SHOULD result in Code-Rejects. 447 Timeouts 449 BCP packets may not be exchanged until PPP has reached the 450 Network-Layer Protocol phase. An implementation SHOULD be 451 prepared to wait for Authentication and Link Quality Determination 452 to finish before timing out waiting for a Configure-Ack or other 453 response. It is suggested that an implementation give up only 454 after user intervention or a configurable amount of time. 456 Configuration Option Types 458 BCP has a distinct set of Configuration Options, which are defined 459 in this document. 461 4.1. Sending Bridge Frames 463 Before any Bridged LAN Traffic or BPDUs may be communicated, PPP MUST 464 reach the Network-Layer Protocol phase, and the Bridging Control 465 Protocol MUST reach the Opened state. 467 Exactly one Bridged LAN Traffic or BPDU is encapsulated in the PPP 468 Information field, where the PPP Protocol field indicates type hex 469 0031 (Bridged PDU). 471 4.1.1. Maximum Receive Unit Considerations 473 The maximum length of a Bridged datagram transmitted over a PPP link 474 is the same as the maximum length of the Information field of a PPP 475 encapsulated packet. Since there is no standard method for 476 fragmenting and reassembling Bridged PDUs, PPP links supporting 477 Bridging MUST negotiate an MRU large enough to support the MAC Types 478 that are later negotiated for Bridging support. Because they include 479 the MAC headers, even bridged Ethernet frames are larger than the 480 default PPP MRU of 1500 octets. 482 4.1.2. Loopback and Link Quality Monitoring 484 It is strongly recommended that PPP Bridge Protocol implementations 485 utilize Magic Number Loopback Detection and Link-Quality-Monitoring. 486 The 802.1 Spanning Tree protocol, which is integral to both 487 Transparent Bridging and Source Routing (as standardized), is 488 unidirectional during normal operation. Configuration BPDUs emanate 489 from the Root system in the general direction of the leaves, without 490 any reverse traffic except in response to network events. 492 4.1.3. Message Sequence 494 The multiple link case requires consideration of message 495 sequentiality. The transmitting system may determine either that the 496 protocol being bridged requires transmissions to arrive in the order 497 of their original transmission, and enqueue all transmissions on a 498 given conversation onto the same link to force order preservation, or 499 that the protocol does NOT require transmissions to arrive in the 500 order of their original transmission, and use that knowledge to 501 optimize the utilization of several links, enqueuing traffic to 502 multiple links to minimize delay. 504 In the absence of such a determination, the transmitting system MUST 505 act as though all protocols require order preservation. Many 506 protocols designed primarily for use on a single LAN require order 507 preservation. 509 PPP Multilink [7] and its multi-class extension [11] may be used to 510 allow the use of multiple PPP links between a pair of systems without 511 loss of message sequentiality. It treats the group of links as a 512 single link with speed equal to the sum of the speeds of the links in 513 the group. 515 4.1.4. Separation of Spanning Tree Domains 517 It is conceivable that a network manager might wish to inhibit the 518 exchange of BPDUs on a link in order to logically divide two regions 519 into separate Spanning Trees with different Roots (and potentially 520 different Spanning Tree implementations or algorithms). In order to 521 do that, he should configure both ends to not exchange BPDUs on a 522 link. An implementation that does not support any spanning tree 523 protocol MUST silently discard any received IEEE 802.1D BPDU packets. 525 If a bridge is connected to an old BCP bridge [10], the other bridge 526 cannot operate according to this specification. Options are therefore 527 to decide that: 529 (a) If the bridge wants to terminate the connection, it sends a 530 Terminate-Request and terminate the connection. 531 (b) If the bridge wants to run the connection but not receive old 532 BPDUs, its only option is to run without spanning tree on the 533 link at all, which is dangerous. It should Configure-Reject 534 the option and advise the network administration that it has 535 done so. 536 (c) If the bridge chooses to be entirely backward compatible, it 537 sends Configure-Ack and operates in the manner described in 538 Appendix A. 540 In the event that both the new Management-Inline Option and the 541 Spanning-Tree-Protocol-Configuration Option are configure-rejected, 542 indicating that the peer implements no spanning tree protocol at all 543 and doesn't understand the options, it is an incomplete 544 implementation. For safety reasons the system should cease attempting 545 to configure bridging, and log the fact. If the peer was configure- 546 rejecting the options in order to disable spanning tree entirely, it 547 understood the option but could not within its configuration comply. 548 It should have sent the Spanning-Tree-Protocol-Configuration Option 549 with the value NULL. 551 Implementations SHOULD implement a backward compatibility mode. 553 4.2. Bridged LAN Traffic (IEEE 802 Untagged Frame) 555 For Bridging LAN traffic, the format of the frame on the line is 556 shown below. This format is used if the traffic does not include VLAN 557 ID and priority. 559 The fields are transmitted from left to right. 561 802.3 Frame format (IEEE 802 Un-tagged Frame) 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+ 566 | HDLC FLAG | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Address and Control | 0x00 | 0x31 | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 |F|0|Z|0| Pads | MAC Type | Destination MAC Address | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Destination MAC Address | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Source MAC Address | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Source MAC Address | Length/Type | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | LLC data ... 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | LAN FCS (optional) | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | potential line protocol pad | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Frame FCS | HDLC FLAG | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 802.4/802.5/FDDI Frame format (IEEE 802 Un-tagged Frame) 589 0 1 2 3 590 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 591 +-+-+-+-+-+-+-+-+ 592 | HDLC FLAG | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Address and Control | 0x00 | 0x31 | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 |F|0|Z|0| Pads | MAC Type | Pad Byte | Frame Control | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Destination MAC Address | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Destination MAC Address | Source MAC Address | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Source MAC Address | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | LLC data ... 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | LAN FCS (optional) | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | optional Data Link Layer padding | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Frame FCS | HDLC FLAG | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 Address and Control 615 As defined by the framing in use. 617 PPP Protocol 619 0x0031 for PPP Bridging 621 Flags 623 bit F: Set if the LAN FCS Field is present 624 bit Z: Set if IEEE 802.3 Pad must be zero filled to minimum size 625 bit 0: reserved, must be zero 627 Pads 629 Any PPP frame may have padding inserted in the "Optional Data Link 630 Layer Padding" field. This number tells the receiving system how 631 many pad octets to strip off. 633 MAC Type 634 Up-to-date values of the MAC Type field are specified in the most 635 recent "Assigned Numbers" RFC [4]. Current values are assigned as 636 follows: 638 0: reserved 639 1: IEEE 802.3/Ethernet with canonical addresses 640 2: IEEE 802.4 with canonical addresses 641 3: IEEE 802.5 with non-canonical addresses 642 4: FDDI with non-canonical addresses 643 5-10: reserved 644 11: IEEE 802.5 with canonical addresses 645 12: FDDI with canonical addresses 647 "Canonical" is the address format defined as standard address 648 representation by the IEEE. In this format, the bit within each 649 byte that is to be transmitted first on a LAN is represented as 650 the least significant bit. In contrast, in non-canonical form, 651 the bit within each byte that is to be transmitted first is 652 represented as the most-significant bit. Many LAN interface 653 implementations use non-canonical form. In both formats, bytes 654 are represented in the order of transmission. 656 If an implementation supports a MAC Type that is the higher- 657 numbered format of that MAC Type, then it MUST also support the 658 lower-numbered format of that MAC Type. For example, if an 659 implementation supports FDDI with canonical address format, then 660 it MUST also support FDDI with non-canonical address format. The 661 purpose of this requirement is to provide backward compatibility 662 with earlier versions of this specification. 664 A system MUST NOT transmit a MAC Type numbered higher than 4 665 unless it has received from its peer a MAC-Support Configuration 666 Option indicating that the peer is willing to receive frames of 667 that MAC Type. 669 Frame Control 671 On 802.4, 802.5, and FDDI LANs, there are a few octets preceding 672 the Destination MAC Address, one of which is protected by the FCS. 674 The MAC Type of the frame determines the contents of the Frame 675 Control field. A pad octet is present to provide 32-bit packet 676 alignment. 678 Destination MAC Address 680 As defined by the IEEE. The MAC Type field defines the bit 681 ordering. 683 Source MAC Address 685 As defined by the IEEE. The MAC Type field defines the bit 686 ordering. 688 LLC data 690 This is the remainder of the MAC frame which is (or would be were 691 it present) protected by the LAN FCS. 693 For example, the 802.5 Access Control field, and Status Trailer 694 are not meaningful to transmit to another ring, and are omitted. 696 LAN FCS 698 If present, this is the LAN FCS which was calculated by (or which 699 appears to have been calculated by) the originating station. If 700 the LAN FCS flag is not set, then this field is not present, and 701 the PDU is four octets shorter. 703 Optional Data Link Layer Padding 705 Any PPP frame may have padding inserted between the Information 706 field and the Frame FCS. The Pads field contains the length of 707 this padding, which may not exceed 15 octets. 709 The PPP LCP Extensions [5] specify a self-describing pad. 710 Implementations are encouraged to set the Pads field to zero, and 711 use the self-describing pad instead. 713 Frame FCS 715 Mentioned primarily for clarity. The FCS used on the PPP link is 716 separate from and unrelated to the LAN FCS. 718 4.3. Bridged LAN Traffic in IEEE 802 Tagged Frame 720 To connect two or more Virtual LAN segments, the frame MUST include 721 its VLAN ID and priority. An IEEE 802 Tagged Frame may be used if the 722 IEEE-802-Tagged-Frame Option is accepted by the peer. The format of 723 the frame on the line is shown below. 725 The fields are transmitted from left to right. 727 802.3 Frame format (IEEE 802 Tagged Frame) 729 0 1 2 3 730 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 731 +-+-+-+-+-+-+-+-+ 732 | HDLC FLAG | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | Address and Control | 0x00 | 0x31 | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 |F|0|Z|0| Pads | MAC Type | Destination MAC Address | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Destination MAC Address | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Source MAC Address | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Source MAC Address | 0x81 | 0x00 | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 |Pri |C| VLAN ID | Length/Type | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | LLC data ... 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | LAN FCS (optional) | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | potential line protocol pad | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | Frame FCS | HDLC FLAG | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 802.4/802.5/FDDI Frame format (IEEE 802 Tagged Frame) 757 0 1 2 3 758 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 759 +-+-+-+-+-+-+-+-+ 760 | HDLC FLAG | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Address and Control | 0x00 | 0x31 | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 |F|0|Z|0| Pads | MAC Type | Pad Byte | Frame Control | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Destination MAC Address | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Destination MAC Address | Source MAC Address | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Source MAC Address | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | SNAP-encoded TPID | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | SNAP-encoded TPID | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 |Pri |C| VLAN ID | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | LLC data ... 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | LAN FCS (optional) | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | optional Data Link Layer padding | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | Frame FCS | HDLC FLAG | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 Address and Control 789 As defined by the framing in use. 791 PPP Protocol 793 0x0031 for PPP Bridging 795 Flags 797 bit F: Set if the LAN FCS Field is present 798 bit Z: Set if IEEE 802.3 Pad must be zero filled to minimum size 799 bit 0: reserved, must be zero 801 Pads 802 Any PPP frame may have padding inserted in the "Optional Data Link 803 Layer Padding" field. This number tells the receiving system how 804 many pad octets to strip off. 806 MAC Type 808 Up-to-date values of the MAC Type field are specified in the most 809 recent "Assigned Numbers" RFC [4]. Current values are assigned as 810 follows: 812 0: reserved 813 1: IEEE 802.3/Ethernet with canonical addresses 814 2: IEEE 802.4 with canonical addresses 815 3: IEEE 802.5 with non-canonical addresses 816 4: FDDI with non-canonical addresses 817 5-10: reserved 818 11: IEEE 802.5 with canonical addresses 819 12: FDDI with canonical addresses 821 "Canonical" is the address format defined as standard address 822 representation by the IEEE. In this format, the bit within each 823 byte that is to be transmitted first on a LAN is represented as 824 the least significant bit. In contrast, in non-canonical form, 825 the bit within each byte that is to be transmitted first is 826 represented as the most-significant bit. Many LAN interface 827 implementations use non-canonical form. In both formats, bytes 828 are represented in the order of transmission. 830 If an implementation supports a MAC Type that is the higher- 831 numbered format of that MAC Type, then it MUST also support the 832 lower-numbered format of that MAC Type. For example, if an 833 implementation supports FDDI with canonical address format, then 834 it MUST also support FDDI with non-canonical address format. The 835 purpose of this requirement is to provide backward compatibility 836 with earlier versions of this specification. 838 A system MUST NOT transmit a MAC Type numbered higher than 4 839 unless it has received from its peer a MAC-Support Configuration 840 Option indicating that the peer is willing to receive frames of 841 that MAC Type. 843 Frame Control 845 On 802.4, 802.5, and FDDI LANs, there are a few octets preceding 846 the Destination MAC Address, one of which is protected by the FCS. 848 The MAC Type of the frame determines the contents of the Frame 849 Control field. A pad octet is present to provide 32-bit packet 850 alignment. 852 Destination MAC Address 854 As defined by the IEEE. The MAC Type field defines the bit 855 ordering. 857 Source MAC Address 859 As defined by the IEEE. The MAC Type field defines the bit 860 ordering. 862 Pri 863 3 bit priority value as defined by IEEE 802.1D. 865 C 866 Canonical flag as defined by IEEE 802.1Q. It must be set if 867 RIF data is present in the LLC data. 869 VLAN ID 870 12 bit VLAN identifier number as defined by IEEE 802.1Q. 872 LLC data 874 This is the remainder of the MAC frame which is (or would be were 875 it present) protected by the LAN FCS. 877 For example, the 802.5 Access Control field, and Status Trailer 878 are not meaningful to transmit to another ring, and are omitted. 880 LAN FCS 882 If present, this is the LAN FCS which was calculated by (or which 883 appears to have been calculated by) the originating station. If 884 the LAN FCS flag is not set, then this field is not present, and 885 the PDU is four octets shorter. 887 Optional Data Link Layer Padding 889 Any PPP frame may have padding inserted between the Information 890 field and the Frame FCS. The Pads field contains the length of 891 this padding, which may not exceed 15 octets. 893 The PPP LCP Extensions [5] specify a self-describing pad. 894 Implementations are encouraged to set the Pads field to zero, and 895 use the self-describing pad instead. 897 Frame FCS 899 Mentioned primarily for clarity. The FCS used on the PPP link is 900 separate from and unrelated to the LAN FCS. 902 4.4. Bridge protocols and GARP protocols 904 To avoid network loops and improve redundancy, Bridges exchange a 905 Spanning Tree Protocol data unit known as BPDU. Bridges also exchange 906 a Generic Attributes Registration Protocol data unit to carry the 907 GARP VLAN Registration Protocol (GVRP) data and GARP Multicast 908 Registration Protocol (GMRP). GVRP allow the Bridges to create VLAN 909 groups dynamically. GMRP allows bridges to filter Multicast data if 910 the receiver is absent from the network. These Bridge protocols 911 include Spanning Tree Protocol and GARP protocols data units are 912 carried with a special destination address assigned by the IEEE. 914 These bridge protocols data units and GARP prptocol data units must 915 be carried in the frame format shown in section 4.2 or 4.3. The 916 Bridge that receives these data units identifies these protocols 917 based on the destination address in the frame format, just like the 918 operation of receiving frames from a LAN segment. 920 Bridge protocols and GARP protocols data units MUST be recognized by 921 checking the destination addresses, which are assigned by IEEE. 923 01-80-c2-00-00-00 Bridge Group Address (used by STP) 924 01-80-c2-00-00-01 IEEE Std. 802.3x Full Duplex PAUSE operation 925 01-80-c2-00-00-10 Bridge Management Group Address 926 01-80-c2-00-00-20 GARP Multicast Registration Protocol (GMRP) 927 01-80-c2-00-00-21 GARP VLAN Registration Protocol (GVRP) 929 But there is one exception to this rule: if the bridge is connected 930 to an old BCP bridge [10] and can support backward compatibility, it 931 MUST send the BPDU in the old format described in Appendix A. 933 5. BCP Configuration Options 935 BCP Configuration Options allow modifications to the standard 936 characteristics of the network-layer protocol to be negotiated. If a 937 Configuration Option is not included in a Configure-Request packet, 938 the default value for that Configuration Option is assumed. 940 BCP uses the same Configuration Option format defined for LCP [6], 941 with a separate set of Options. 943 Up-to-date values of the BCP Option Type field are specified in the 944 most recent "Assigned Numbers" RFC [4]. Current values are assigned 945 as follows: 947 1 Bridge-Identification 948 2 Line-Identification 949 3 MAC-Support 950 4 Tinygram-Compression 951 5 LAN-Identification (obsoleted) 952 6 MAC-Address 953 7 Spanning-Tree-Protocol (old formatted) 954 8 IEEE 802 Tagged Frame 955 9 Management Inline 957 5.1. Bridge-Identification 959 Description 961 The Bridge-Identification Configuration Option is designed for use 962 when the line is an interface between half bridges connecting 963 virtual or physical LAN segments. Since these remote bridges are 964 modeled as a single bridge with a strange internal interface, each 965 remote bridge needs to know the LAN segment and bridge numbers of 966 the adjacent remote bridge. This option MUST NOT be included in 967 the same Configure-Request as the Line-Identification option. 969 The Source Routing Route Descriptor and its use are specified by 970 the IEEE 802.1D Appendix on Source Routing. It identifies the 971 segment to which the interface is attached by its configured 972 segment number, and itself by bridge number on the segment. 974 The two half bridges MUST agree on the bridge number. If a bridge 975 number is not agreed upon, the Bridging Control Protocol MUST NOT 976 enter the Opened state. 978 Since mismatched bridge numbers are indicative of a configuration 979 error, a correct configuration requires that either the bridge 980 declare the misconfiguration or choose one of the options. To 981 allow two systems to proceed to the Opened state despite a 982 mismatch, a system MAY change its bridge number to the higher of 983 the two numbers. A higher-numbered system MUST NOT change its 984 bridge number to a lower number. It should, however, inform 985 the network administration of the misconfiguration in any case. 987 By default, a system that does not negotiate this option is 988 assumed to be configured not to use the model of the two systems 989 as two halves of a single source-route bridge. It is instead 990 assumed to be configured to use the model of the two systems as 991 two independent bridges. 993 Example 995 If System A announces LAN Segment AAA, Bridge #1, and System B 996 announces LAN Segment BBB, Bridge #1, then the resulting Source 997 Routing configuration (read in the appropriate direction) is then 998 AAA,1,BBB. 1000 A summary of the Bridge-Identification Option format is shown below. 1001 The fields are transmitted from left to right. 1003 0 1 2 3 1004 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 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | Type | Length | LAN Segment Number |Bridge#| 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 Type 1011 1 1013 Length 1015 4 1017 LAN Segment Number 1019 A 12-bit number identifying the LAN segment, as defined in the 1020 IEEE 802.1D Source Routing Specification. 1022 Bridge Number 1024 A 4-bit number identifying the bridge on the LAN segment, as 1025 defined in the IEEE 802.1D Source Routing Specification. 1027 5.2. Line-Identification 1029 Description 1031 The Line-Identification Configuration Option is designed for use 1032 when the line is assigned a LAN segment number as though it were a 1033 two system LAN segment in accordance with the Source Routing 1034 algorithm. 1036 The Source Routing Route Descriptor and its use are specified by 1037 the IEEE 802.1D Appendix on Source Routing. It identifies the 1038 segment to which the interface is attached by its configured 1039 segment number, and itself by bridge number on the segment. 1041 The two bridges MUST agree on the LAN segment number. If a LAN 1042 segment number is not agreed upon, the Bridging Control Protocol 1043 MUST NOT enter the Opened state. 1045 Since mismatched LAN segment numbers are indicative of a 1046 configuration error, a correct configuration requires that either 1047 the bridge declare the misconfiguration or choose one of the 1048 options. To allow two systems to proceed to the Opened state 1049 despite a mismatch, a system MAY change its LAN segment number to 1050 the higher of the two numbers. A higher-numbered system MUST NOT 1051 change its LAN segment number to a lower number. It should, 1052 however, 1053 inform the network administration of the misconfiguration in any 1054 case. 1056 By default, a system that does not negotiate this option is 1057 assumed to have its LAN segment number correctly configured by the 1058 user. 1060 A summary of the Line-Identification Option format is shown below. 1061 The fields are transmitted from left to right. 1063 0 1 2 3 1064 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 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | Type | Length | LAN Segment Number |Bridge#| 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 Type 1071 2 1073 Length 1075 4 1077 LAN Segment Number 1079 A 12-bit number identifying the LAN segment, as defined in the 1080 IEEE 802.1D Source Routing Specification. 1082 Bridge Number 1084 A 4-bit number identifying the bridge on the LAN segment, as 1085 defined in the IEEE 802.1D Source Routing Specification. 1087 5.3. MAC-Support 1089 Description 1091 The MAC-Support Configuration Option is provided to permit 1092 implementations to indicate the sort of traffic they are prepared 1093 to receive. Negotiation of this option is strongly recommended. 1095 By default, when an implementation does not announce the MAC Types 1096 that it supports, all MAC Types are sent by the peer which are 1097 capable of being transported given other configuration parameters. 1098 The receiver will discard those MAC Types that it does not 1099 support. 1101 A device supporting a 1600 octet MRU might not be willing to 1102 support 802.5, 802.4 or FDDI, which each support frames larger 1103 than 1600 octets. 1105 By announcing the MAC Types it will support, an implementation is 1106 advising its peer that all unspecified MAC Types will be 1107 discarded. The peer MAY then reduce bandwidth usage by not 1108 sending the unsupported MAC Types. 1110 Announcement of support for multiple MAC Types is accomplished by 1111 placing multiple options in the Configure-Request. 1113 The nature of this option is advisory only. This option MUST NOT 1114 be included in a Configure-Nak. 1116 A summary of the MAC-Support Option format is shown below. The 1117 fields are transmitted from left to right. 1119 0 1 2 1120 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | Type | Length | MAC Type | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 Type 1127 3 1129 Length 1131 3 1133 MAC Type 1135 One of the values of the PDU MAC Type field (previously described 1136 in the "Bridged LAN Traffic" section) that this system is prepared 1137 to receive and service. 1139 5.4. Tinygram-Compression 1141 Description 1143 This Configuration Option permits the implementation to indicate 1144 support for Tinygram compression. 1146 Not all systems are prepared to make modifications to messages in 1147 transit. On high speed lines, it is probably not worth the 1148 effort. 1150 This option MUST NOT be included in a Configure-Nak if it has been 1151 received in a Configure-Request. This option MAY be included in a 1152 Configure-Nak in order to prompt the peer to send the option in 1153 its next Configure-Request. 1155 By default, no compression is allowed. A system which does not 1156 negotiate, or negotiates this option to be disabled, should never 1157 receive a compressed packet. 1159 A summary of the Tinygram-Compression Option format is shown below. 1160 The fields are transmitted from left to right. 1162 0 1 2 1163 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | Type | Length | Enable/Disable| 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 Type 1170 4 1172 Length 1174 3 1176 Enable/Disable 1178 If the value is 1, Tinygram-Compression is enabled. If the value 1179 is 2, Tinygram-Compression is disabled, and no decompression will 1180 occur. 1182 The implementations need not agree on the setting of this 1183 parameter. One may be willing to decompress and the other not. 1185 5.5. MAC-Address 1187 Description 1189 The MAC-Address Configuration Option enables the implementation to 1190 announce its MAC address or have one assigned. The MAC address is 1191 represented in IEEE 802.1 Canonical format, which is to say that 1192 the multicast bit is the least significant bit of the first octet 1193 of the address. 1195 If the system wishes to announce its MAC address, it sends the 1196 option with its MAC address specified. When specifying a non-zero 1197 MAC address in a Configure-Request, any inclusion of this option 1198 in a Configure-Nak MUST be ignored. 1200 If the implementation wishes to have a MAC address assigned, it 1201 sends the option with a MAC address of 00-00-00-00-00-00. Systems 1202 that have no mechanism for address assignment will Configure- 1203 Reject the option. 1205 A Configure-Nak MUST specify a valid IEEE 802.1 format physical 1206 address; the multicast bit MUST be zero. It is strongly 1207 recommended (although not mandatory) that the "locally assigned 1208 address" bit (the second least significant bit in the first octet) 1209 be set, indicating a locally assigned address. 1211 A summary of the MAC-Address Option format is shown below. The 1212 fields are transmitted from left to right. 1214 0 1 2 3 1215 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 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | Type | Length |MAC byte 1 |L|M| MAC byte 2 | 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 | MAC byte 3 | MAC byte 4 | MAC byte 5 | MAC byte 6 | 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 Type 1224 6 1226 Length 1228 8 1230 MAC Byte 1232 Six octets of MAC address in 802.1 Canonical order. For clarity, 1233 the position of the Local Assignment (L) and Multicast (M) bits 1234 are shown in the diagram. 1236 5.6. Spanning-Tree-Protocol (old format) 1238 Description 1240 The Spanning-Tree-Protocol Configuration enables a Bridge to 1241 remain compatible with older implementations of BCP [10]. This 1242 configuration option is, however, incompatible with the 1243 Management-Inline option, which enables a bridge to implement the 1244 many protocols that IEEE now expects a bridge to be able to use. 1246 If the peer rejects the Management-Inline configuration option, by 1247 sending configure-reject, it must be an implementation of [10], 1248 which is described in Appendix A. The system may optionally 1249 terminate the negotiation or offer to negotiate in that manner. 1251 In this case, if both bridges support a spanning tree protocol, 1252 they MUST agree on the protocol to be supported. The old BPDU 1253 described in Appendix A MUST be used rather than the format 1254 shown in section 4.2 or 4.3. When the two disagree, the 1255 lower-numbered of the two spanning tree protocols should be used. 1256 To resolve the conflict, the system with the lower-numbered 1257 protocol SHOULD Configure-Nak the option, suggesting its own 1258 protocol for use. If a spanning tree protocol is not agreed upon, 1259 except for the case in which one system does not support any 1260 spanning tree protocol, the Bridging Control Protocol MUST NOT 1261 enter the Opened state. 1263 Most systems will only participate in a single spanning tree 1264 protocol. If a system wishes to participate simultaneously in 1265 more than one spanning tree protocol, it MAY include all of the 1266 appropriate protocol types in a single Spanning-Tree-Protocol 1267 Configuration Option. The protocol types MUST be specified in 1268 increasing numerical order. For the purpose of comparison during 1269 negotiation, the protocol numbers MUST be considered to be a 1270 single number. For instance, if System A includes protocols 01 1271 and 03 and System B indicates protocol 03, System B should 1272 Configure-Nak and indicate a protocol type of 03 since 0103 is 1273 greater than 03. 1275 By default, an implementation MUST either support the IEEE 802.1D 1276 spanning tree or support no spanning tree protocol. An 1277 implementation that does not support any spanning tree protocol 1278 MUST silently discard any received IEEE 802.1D BPDU packets, and 1279 MUST either silently discard or respond to other received BPDU 1280 packets with an LCP Protocol-Reject packet in this case. 1282 A summary of the Spanning-Tree-Protocol Option format is shown below. 1283 The fields are transmitted from left to right. 1285 0 1 2 3 1286 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 2 3 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1288 | Type | Length | Protocol 1 | Protocol 2 | .. 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1291 Type 1293 7 1295 Length 1297 2 octets plus 1 additional octet for each protocol that will be 1298 actively supported. Most systems will only support a single 1299 spanning tree protocol, resulting in a length of 3. 1301 Protocol n 1303 Each Protocol field is one octet and indicates a desired spanning 1304 tree protocol. Up-to-date values of the Spanning-Tree-Protocol 1305 field 1306 are specified as PPP DLL numbers in the most recent "Assigned 1307 Numbers" RFC [4]. Current values are assigned as follows: 1309 Value Protocol 1311 0 Null (no Spanning Tree protocol supported) 1312 1 IEEE 802.1D spanning tree 1313 2 IEEE 802.1G extended spanning tree protocol 1314 3 IBM Source Route Spanning tree protocol 1315 4 DEC LANbridge 100 Spanning tree protocol 1317 5.7. IEEE-802-Tagged-Frame 1319 Description 1321 This configuration option permits the implementation to 1322 indicate support for IEEE 802 Tagged Frame. Negotiation 1323 of this option is strongly recommended. 1325 A device supporting IEEE 802 Tagged Frame must be willing 1326 to support IEEE 802 Tagged Frame shown in section 4.3. 1328 By default, IEEE 802 Tagged Frame is not supported. A system 1329 which does not negotiate, or negotiates this option to be 1330 disabled, should never receive a IEEE 802 Tagged Frame. 1332 A summary of the IEEE 802 Tagged Frame Option format is shown below. 1333 The fields are transmitted from left to right. 1335 0 1 2 1336 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 | Type | Length | Enable/Disable| 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 Type 1343 8 1345 Length 1347 3 1349 Enable/Disable 1351 If the value is 1, IEEE-802-Tagged-Frame is enabled. If the 1352 value is 2, IEEE-802-Tagged-Frame is disabled, and MUST not 1353 send any IEEE-802-Tagged-Frame packet. 1355 5.8. Management-Inline 1357 Description 1359 The Management-Inline Configuration Option indicates that the 1360 system is willing to receive any IEEE-defined inter-bridge 1361 protocols, such as bridge protocol data units and GARP 1362 protocol data units, in the frame format shown in section 1363 4.2 or 4.3. 1365 Old BCP [10] implementations will use the negotiation 1366 procedure described in section 5.6. Implementations of this 1367 procedure will use this option to indicate compliance with 1368 the new BCP and may optionally negotiate the section 5.6 1369 procedure, either on the same configure-request or in response 1370 to a configure-reject, as well. It is recommended that the 1371 configure-request only show this option when it is relevant, 1372 and that it reply with the Spanning-Tree-Protocol 1373 (old formatted) option if a configure-reject is received, 1374 as in the normal case one can expect it to be the quickest 1375 negotiation. 1377 If a system receives a configure-request offering both 1378 alternatives, it should accept this procedure and reject the 1379 Spanning-Tree-Protocol (old format) option. 1381 One can expect old BCP [10] implementations to not understand 1382 the option and issue a configure-reject. 1384 By default, Management-Inline is not allowed. A system which 1385 does not negotiate, or negotiates this option to be disabled, 1386 should never receive a Bridge Protocol data unit or GARP 1387 protocol data unit inline. 1389 A summary of the Management-Inline Option format is shown 1390 below. The fields are transmitted from left to right. 1392 0 1 1393 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 | Type | Length | 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 Type 1400 9 1402 Length 1404 2 1406 6. Change Log 1408 This section enumerates changes made to old BCP [10] to produce this 1409 document. 1411 (1) Remove all LAN Identification descriptions and replace with IEEE 1412 802.1Q VLAN descriptions. 1413 (2) Remove LAN Identification field from frame format and I flags 1414 from flag field. 1415 (3) Merge the Spanning Tree BPDU frame format with Bridged 1416 traffic. 1418 7. Security Considerations 1420 This network control protocol compares the configurations of two 1421 devices and seeks to negotiate an acceptable subset of their 1422 intersection, to enable correct interoperation even in the presence 1423 of minor configuration or implementation differences. In the event 1424 that a major misconfiguration is detected, the negotiation will not 1425 complete successfully, resulting in the link coming down or not 1426 coming up. It is possible that if a bridged link comes up with a 1427 rogue peer, network information may be learned from forwarded 1428 multicast traffic, or denial of service attacks may be created by 1429 closing loops that should be detected and isolated or by offering 1430 rogue load. 1432 Such attacks are not isolated to this NCP; any PPP NCP is subject to 1433 attack when connecting to a foreign or compromised device. However, 1434 no situations arise which are not common to all NCPs; any NCP that 1435 comes up with a rogue peer is subject to snooping and other attacks. 1436 Therefore, it is recommended that links on which this may happen 1437 should be configured to use PPP authentication during the LCP start- 1438 up phase. 1440 8. Intellectual Property Notice 1442 The IETF takes no position regarding the validity or scope of any 1443 intellectual property or other rights that might be claimed to 1444 pertain to the implementation or use of the technology described in 1445 this document or the extent to which any license under such rights 1446 might or might not be available; neither does it represent that it 1447 has made any effort to identify any such rights. Information on the 1448 IETF's procedures with respect to rights in standards-track and 1449 standards-related documentation can be found in BCP-11. Copies of 1450 claims of rights made available for publication and any assurances of 1451 licenses to be made available, or the result of an attempt made to 1452 obtain a general license or permission for the use of such 1453 proprietary rights by implementers or users of this specification can 1454 be obtained from the IETF Secretariat." 1456 The IETF invites any interested party to bring to its attention any 1457 copyrights, patents or patent applications, or other proprietary 1458 rights which may cover technology that may be required to practice 1459 this standard. Please address the information to the IETF Executive 1460 Director. 1462 The IETF has been notified of intellectual property rights claimed in 1463 regard to some or all of the specification contained in this 1464 document. For more information consult the online list of claimed 1465 rights. 1467 9. IANA Considerations 1469 This document proposes a total of two new BCP option numbers to be 1470 maintained by the IANA. These options (described in Section 5.1 and 1471 5.2) are IEEE-802-Tagged-Frame and Management-Inline. It is expected 1472 that IANA will assign the values 8 and 9 respectively for these 1473 option numbers. 1475 10. Acknowledgments 1477 This document is a product of the Point-to-Point Protocol Extensions 1478 Working Group. 1480 This document is based on the proposed Standard PPP Bridging Control 1481 Protocol, RFC 1638 [10], edited by Rich Bowen of IBM and produced by 1482 the Point-to-Point Protocol Extensions Working Group. It extends that 1483 document by providing support for Virtual LANs as outlined in [9]. 1485 A. Spanning Tree Bridge PDU (old format) 1487 By default, Spanning Tree BPDUs MUST be encoded with a MAC or 802.2 1488 LLC header as described in section 4.2 or 4.3 of this document. 1489 However, should the remote entity Configure-Reject the Management- 1490 Inline option, thereby indicating that it is a purely RFC 1638 1491 compliant device, the local entity may subsequently encode BPDUs as 1492 described in section 4.3 of RFC 1638 provided that use of a suitable 1493 non-NULL STP protocol across the link is successfully negotiated 1494 using the (old) Spanning-Tree-Protocol option. 1496 This is the Spanning Tree BPDU used in RFC 1638, without any MAC or 1497 802.2 LLC header (these being functionally equivalent to the Address, 1498 Control, and PPP Protocol Fields). The LAN Pad and Frame Checksum 1499 fields are likewise superfluous and absent. 1501 The Address and Control Fields are subject to LCP Address-and- 1502 Control-Field-Compression negotiation. 1504 A PPP system which is configured to participate in a particular 1505 spanning tree protocol and receives a BPDU of a different spanning 1506 tree protocol SHOULD reject it with the LCP Protocol-Reject. A 1507 system which is configured not to participate in any spanning tree 1508 protocol MUST silently discard all BPDUs. 1510 Spanning Tree Bridge PDU 1512 0 1 2 3 1513 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 1514 +-+-+-+-+-+-+-+-+ 1515 | HDLC FLAG | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | Address and Control | Spanning Tree Protocol | 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 | BPDU data ... | 1520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 | Frame FCS | HDLC FLAG | 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 Address and Control 1526 As defined by the framing in use. 1528 Spanning Tree Protocol 1530 Up-to-date values of the Spanning-Tree-Protocol field are 1531 specified in the most recent "Assigned Numbers" RFC [4]. Current 1532 values are assigned as follows: 1534 Value (in hex) Protocol 1536 0201 IEEE 802.1 (either 802.1D or 802.1G) 1537 0203 IBM Source Route Bridge 1538 0205 DEC LANbridge 100 1540 The two versions of the IEEE 802.1 spanning tree protocol frames 1541 can be distinguished by fields within the BPDU data. 1543 BPDU data 1545 As defined by the specified Spanning Tree Protocol. 1547 B. Tinygram-Compression Pseudo-Code 1549 PPP Transmitter: 1551 if (ZeroPadCompressionEnabled && 1552 BridgedProtocolHeaderFormat == IEEE8023 && 1553 PacketLength == Minimum8023PacketLength) { 1554 /* 1555 * Remove any continuous run of zero octets preceding, 1556 * but not including, the LAN FCS, but not extending 1557 * into the MAC header. 1558 */ 1559 Set (ZeroCompressionFlag); /* Signal receiver */ 1560 if (is_Set (LAN_FCS_Present)) { 1561 FCS = TrailingOctets (PDU, 4); /* Store FCS */ 1562 RemoveTrailingOctets (PDU, 4); /* Remove FCS */ 1563 while (PacketLength > 14 && /* Stop at MAC header or */ 1564 TrailingOctet (PDU) == 0) /* last non-zero octet */ 1565 RemoveTrailingOctets (PDU, 1);/* Remove zero octet */ 1566 Appendbuf (PDU, 4, FCS); /* Restore FCS */ 1567 } 1568 else { 1569 while (PacketLength > 14 && /* Stop at MAC header */ 1570 TrailingOctet (PDU) == 0) /* or last zero octet */ 1571 RemoveTrailingOctets (PDU, 1);/* Remove zero octet */ 1572 } 1573 } 1575 PPP Receiver: 1577 if (ZeroCompressionFlag) { /* Flag set in header? */ 1578 /* Restoring packet to minimum 802.3 length */ 1579 Clear (ZeroCompressionFlag); 1580 if (is_Set (LAN_FCS_Present)) { 1581 FCS = TrailingOctets (PDU, 4); /* Store FCS */ 1582 RemoveTrailingOctets (PDU, 4); /* Remove FCS */ 1583 Appendbuf (PDU, 60 - PacketLength, zeroes);/* Add zeroes */ 1584 Appendbuf (PDU, 4, FCS); /* Restore FCS */ 1585 } 1586 else { 1587 Appendbuf (PDU, 60 - PacketLength, zeroes);/* Add zeroes */ 1588 } 1589 } 1591 C. References 1593 [1] IBM, "Token-Ring Network Architecture Reference", 3rd edition, 1594 September 1989. 1596 [2] IEEE 802.1, "Draft Standard 802.1G: Remote MAC Bridging", 1597 P802.1G/D7, December 30, 1992. 1599 [3] IEEE 802.1D-1993, "Media Access Control (MAC) Bridges", ISO/IEC 1600 15802-3:1993 ANSI/IEEE Std 802.1D, 1993 edition., July 1993. 1602 [4] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1603 1700, October 1994. See also: 1604 http://www.iana.org/numbers.html 1606 [5] Simpson, W., "PPP LCP Extensions", RFC 1570, Daydreamer, 1607 January 1994. 1609 [6] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1610 RFC 1661, July 1994. 1612 [7] K. Sklower, B. Lloyd, G. McGregor, D. Carr & T. Coradetti., 1613 "The PPP Multilink Protocol (MP)", RFC 1990, August 1996. 1615 [8] IEEE 802.1D-1998, "Information technology - Telecommunications 1616 and Information exchange between systems - Local and 1617 metropolitan area networks - Common Specifications - Part 3: 1618 Media Access Control (MAC) Bridges: Revision. This is a revision 1619 of ISO/IEC 10038: 1993, 802.1j-1992 and 802.6k-1992. It 1620 incorporates P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3: 1621 1998. 1623 [9] IEEE 802.1Q, ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local 1624 and Metropolitan Area Networks: Virtual Bridged Local Area 1625 Networks", 1998. 1627 [10] F. Baker and R. Bowen, "PPP Bridging Control Protocol (BCP)", 1628 RFC 1638, June 1994. 1630 [11] C. Bormann, "The Multi-Class Extension to Multi-Link PPP", 1631 RFC 2686, September 1999. 1633 [12] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1634 Levels", RFC 2119, March 1997. 1636 Author's Address 1638 Questions about this memo can also be directed to: 1640 Mitsuru Higashiyama 1641 Anritsu Corporation 1642 1800 Onna, Atsugi-shi, Kanagawa-prf., 243 Japan 1643 Phone: +81 (46) 296-6625 1644 Email: Mitsuru.Higashiyama@yy.anritsu.co.jp 1646 Fred Baker 1647 519 Lado Drive 1648 Santa Barbara, California 93111 1649 Email: fred.baker@cisco.com 1651 Full Copyright Statement 1653 Copyright (C) The Internet Society (2000). All Rights Reserved. 1655 This document and translations of it may be copied and furnished to 1656 others, and derivative works that comment on or otherwise explain it 1657 or assist in its implementation may be prepared, copied, published 1658 and distributed, in whole or in part, without restriction of any 1659 kind, provided that the above copyright notice and this paragraph are 1660 included on all such copies and derivative works. However, this 1661 document itself may not be modified in any way, such as by removing 1662 the copyright notice or references to the Internet Society or other 1663 Internet organizations, except as needed for the purpose of 1664 developing Internet standards in which case the procedures for 1665 copyrights defined in the Internet Standards process must be 1666 followed, or as required to translate it into languages other than 1667 English. 1669 The limited permissions granted above are perpetual and will not be 1670 revoked by the Internet Society or its successors or assigns. 1672 This document and the information contained herein is provided on an 1673 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1674 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1675 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1676 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1677 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.