idnits 2.17.1 draft-ietf-iporpr-basic-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 714. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 725. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 732. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 738. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (August 21, 2006) is 6457 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2598 (ref. '8') (Obsoleted by RFC 3246) ** Downref: Normative reference to an Informational RFC: RFC 4594 (ref. '9') == Outdated reference: A later version (-07) exists of draft-ietf-tsvwg-diffserv-class-aggr-00 ** Downref: Normative reference to an Informational draft: draft-ietf-tsvwg-diffserv-class-aggr (ref. '10') -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPoRPR Working Group M. Holness 3 Internet-Draft G. Parsons 4 Intended status: Standards Track Nortel 5 Expires: February 22, 2007 August 21, 2006 7 Mapping of IP/MPLS packets into IEEE 802.17 (Resilient packet ring) 8 Networks 9 draft-ietf-iporpr-basic-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 22, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document specifies a basic standard method of encapsulating 43 IPv4, IPv6, and MPLS datagrams into IEEE 802.17 Resilient packet ring 44 (RPR) datagrams. 46 Conventions used in this document 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC 2119 [1]. 52 The term "Higher Layer" refers to IPv4, IPv6, and MPLS when they act 53 as clients of the IEEE 802.17 network. 55 "IP" refers to both IPv4 and IPv6. The terms "IPv4" and "IPv6" are 56 used only when a specific version of IP is meant. 58 1. Introduction 60 This document gives a definition of how to transport IP/MPLS over 61 IEEE 802.17 RPR in "basic mode". In basic mode, higher layers do not 62 have any control over the underlying network and treat it as a 63 broadcast media. This document will describe all the necessary 64 mappings to aid interoperable networks. This includes encapsulation 65 formats (e.g., IPv4/IPv6), how to perform address resolution (e.g., 66 ARP/ND), IP multicast transmission, and priority mapping to the RPR 67 service class. 69 2. IEEE 802.17 71 This section gives a brief introduction to the IEEE 802.17 protocol. 72 The intent is to provide information needed to understand the rest of 73 this document. This section SHALL NOT be used as a definitive 74 description of IEEE 802.17 [2] or amendments IEEE 802.17a [14], and 75 IEEE 802.17b [15]. 77 IEEE 802.17 SHALL be consulted for specific details on the 78 functionality. Clause 5 of 802.17 contains a ~30 page overview of 79 the ~700 page specification. Details on the MAC service is contained 80 in Clause 6 of 802.17. 82 2.1. Overview of IEEE 802.17 84 IEEE 802.17 is a dual, counter-rotating, ring network technology with 85 destination stripping. In the event of a fault (such as a fiber cut) 86 the stations on each side of the fault can continue to function by 87 wrapping the ring and/or by steering away from the fault and towards 88 the operational path. 90 The ring is composed of two ringlets, called ringlet0 and ringlet1. 92 A station may transmit a frame in either direction around the ring. 93 IEEE 802.17 includes MAC-level protocols to determine the default 94 path to each destination. The determination of default may be by any 95 algorithm, including shortest path. Normally, the 802.17 MAC layer 96 will automatically send frames via the default path. Alternatively, 97 higher layers (such as IP) may explicitly specify the ringlet to use. 99 All stations on the ring have 48-bit IEEE 802 addresses. 101 IEEE 802.17 is a media-independent network protocol that is layered 102 over several different physical media. SONET/SDH, Gigabit Ethernet 103 and 10-Gigabit Ethernet are currently specified. The higher layers 104 are shielded from any media dependencies. 106 There are three service classes: classA provides committed bandwidth 107 and low delay and jitter, classB has committed and excess bandwidth 108 components and bounded delay and jitter, and classC is best-effort. 110 There are several frame types, one of which is a data frame. The 111 data frame contains a payload (such as an IPv4, IPv6, or MPLS 112 packet). The type of the payload is indicated by a 2-byte type 113 field. The type-field is identical to the type field in IEEE 802.3 114 Ethernet. 116 There is a TTL in the IEEE 802.17 frame headers. This TTL is used to 117 measure and limit the lifetime of frames on a ring. 119 2.2. IEEE 802.17 MAC service 121 The IEEE 802.17 MAC service definition defines the MA_DATA.request 122 primitive which a station uses to transmit data (see section 6.4.1 of 123 [2]). This primitive takes several parameters (only three of which, 124 noted with '*', are mandatory): 126 *destination_address 128 source_address 130 *mac_service_data_unit 132 frame_check_sequence 134 *service_class 136 ringlet_id 138 mac_protection 140 mark_fe 142 strict_order 144 destination_address_extended 146 source_address_extended 148 flooding_form 150 2.2.1. IEEE 802.17 addressing 152 The destination address (DA) [destination_address] is the 48-bit MAC 153 address of the destination station. This may also be a multicast or 154 broadcast address. This is a required parameter. 156 The source address (SA) [source_address] is the 48-bit MAC address of 157 the source station. This is an optional parameter. If it is 158 omitted, the MAC uses the source address that is assigned to the 159 station. 161 2.2.2. IEEE 802.17 payload 163 The MAC SDU [mac_service_data_unit] is the RPR payload. It includes 164 the entire IP/MPLS packet prefaced with the protocol type field. 166 This is a required parameter. 168 2.2.3. IEEE 802.17 service Classes 170 One of the key features of RPR that can distinguish it from other 171 network interconnects, is it ability to support multiple service 172 qualities. Per service quality flow control protocols regulate 173 traffic introduced by clients. The list of supported service classes 174 are listed below: 176 classA: classA service provides an allocated, guaranteed data rate, 177 and low end-to-end delay and jitter bound. classA traffic 178 is allocated with a committed information rate (CIR). 179 Traffic above the allocated rate is rejected. classA 180 traffic has precedence over classB and classC traffic at 181 the ingress to the ring and in transit. This class is well 182 suited for real time applications. 184 classB: classB service provides an allocated, guaranteed data rate, 185 and bounded end-to-end delay and jitter for the traffic 186 within the allocated rate. classB also provides access to 187 additional best effort data transmission that is not 188 allocated, guaranteed, or bounded. classB traffic is 189 allocated with a CIR component. Any classB traffic amount 190 beyond the allocated CIR is referred to as excess 191 information rate (EIR) classB traffic. classB traffic 192 (including classB-EIR) has precedence over classC traffic 193 at the ingress to the ring. 195 classC: classC service provides a best-effort traffic service with 196 non allocated or guaranteed data rate, and no bounds on 197 end-to-end delay or jitter. classC traffic has the lowest 198 precedence for ingress to the ring. Both classB-EIR and 199 classC traffic is governed by the RPR fairness algorithm 200 which ensures proper partitioning of opportunistic traffic 201 over the ring. This class is well suited for best effort 202 applications. 204 Internal to the RPR MAC, classA traffic is partitioned into two sub 205 classes: subclassA0 and subclassA1. This partitioning is done in 206 order to increase the ability of the ring to reclaim unused classA 207 traffic. The RPR MAC is configured for a total classA amount, from 208 which it determines how much is subclassA0 and subclassA1. The 209 division of classA is based on ring circumference and the size of 210 internal transit queues. The reclaimable bandwidth allocated to 211 subclassA1 can be reclaimed by traffic of classB-EIR and classC when 212 not being used by the station originating the classA traffic being 213 reclaimed. Note that subclassA0 is not reclaimable, i.e. this 214 bandwidth is reserved and not available for classB or classC traffic. 216 The RPR datagram carries the priority (i.e., service class) of the 217 traffic being transported within a sc (service class) field found 218 within the baseControl field of the RPR header. 220 2.2.4. IEEE 802.17 fairness 222 The RPR fairness algorithm ensures proper partitioning of 223 opportunistic traffic over the ring and governs classB-EIR and classC 224 traffic. The mark_fe parameter indicate a request to mark and treat 225 a frame as fairness eligible regardless of how it would have been 226 marked or treated otherwise. This guides the MAC entity on how to 227 set the fe (fairness eligible) field. 229 The RPR datagram conveys the application of the fairness algorithm on 230 the datagram by the value of the fairness eligible (fe) field, found 231 in the baseControl field of the RPR header. 233 3. General mapping details 235 This section covers issues that are common to IPv4, IPv6, and MPLS. 237 3.1. IEEE 802.17 MAC service parameters 239 When transmitting an IP or MPLS packet, a host or router indicates 240 various parameters to the IEEE 802.17 MAC layer (see section 6.4 of 241 [2]). This section specifies how those parameters are to be used. 243 3.1.1. Destination_address 245 Is the 48-bit MAC address of the 802.17 station to which the packet 246 is being transmitted. 248 3.1.2. Source_address 250 The source_address SHOULD be the address assigned to the station that 251 is transmitting the packet. Per [2] if the client omits this 252 parameter then the MAC inserts the correct address. 254 3.1.3. mac_service_data_unit 256 This is the payload, including the protocol type field. See 257 "Protocol Type Field" (Section 3.2), for more information. 259 3.1.4. frame_check_sequence 261 The MAC will calculate the FCS 263 3.1.5. serviceClass 265 Specific service class mapping from DSCP and EXP within the client 266 payload SHOULD be used to determine the RPR service class. These 267 mappings are shown in Section 4.2 and Section 6.1. 269 3.1.6. ringlet_id 271 The client SHOULD NOT specify the ringletID. The MAC will use its 272 default algorithm to select a ringlet. 274 3.1.7. mac_protection 276 This parameter SHOULD NOT be specified. The IEEE 802.17 MAC will 277 then use its default treatment 279 3.1.8. mark_fe 281 This parameter SHOULD NOT be specified unless the RPR service class 282 is CLASS B as indicated from the mappings in Section 4.2 and 283 Section 6.1. 285 3.1.9. strict_order 287 This parameter SHOULD NOT be specified. The IEEE 802.17 MAC will 288 then use its default treatment. 290 3.1.10. destination_address_extended 292 This parameter SHOULD NOT be specified. The IEEE 802.17 MAC will 293 populate if necessary. 295 3.1.11. source_address_extended 297 This parameter SHOULD NOT be specified. The IEEE 802.17 MAC will 298 populate if necessary. 300 3.1.12. flooding_form 302 This parameter SHOULD NOT be specified. The IEEE 802.17 MAC will 303 populate if necessary. 305 3.2. Protocol Type Field 307 The 16-bit protocol type field (or Ethertype) is set to a value to 308 indicate the payload protocol. The values for IPv4, IPv6, and MPLS 309 are: 311 0x0800 If the payload contains an IPv4 packet. 313 0x0806 If the payload contains an ARP packet. 315 0x86DD If the payload contains an IPv6 packet. 317 0x8847 If the payload contains a MPLS Unicast packet. 319 0x8848 if the payload contains a MPLS Multicast packet. 321 3.3. Payload 323 The payload contains the IPv4, IPv6, or MPLS packet. The first byte 324 of the IPv4 header, IPv6 header, or top MPLS label begins immediately 325 after the 802.17 header. 327 Note that in 802.17 there is no minimum size for frames carried over 328 Ethernet physical layers, thus there is no need to pad frames that 329 are shorter than the minimum size. However, the robustness principle 330 dictates that nodes be able to handle frames that are padded. 332 Like 802.3 Ethernet, 802.17 defines the maximum regular frame payload 333 as 1500 bytes. Note that a maximum jumbo frame payload size that MAY 334 be supported is defined at 9100 bytes. 336 3.4. Byte Order 338 As described in "APPENDIX B: Data Transmission Order" of RFC 791 [3], 339 IP and MPLS datagrams are transmitted over the IEEE 802.17 network as 340 a series of 8-bit bytes in "big endian" order. This is the same byte 341 order as used for Ethernet. 343 3.5. Ringlet Selection 345 IEEE 802.17 allows the higher layer to select the direction around 346 the ring that traffic is to go. If the higher layer does not make 347 the selection then the IEEE 802.17 MAC makes the decision. For basic 348 mode ringlet selection is left to the MAC. 350 3.6. Higher layer TTL and ring TTL 352 There is no correlation or interaction between the higher layer TTL 353 and the IEEE 802.17 TTL. 355 4. IPv4 specific mapping details 357 4.1. Address resolution 359 ARP [4] is used to map IPv4 addresses to the appropriate MAC address. 360 The "Hardware Address Space" parameter (ar$hrd) used for IEEE 802.17 361 networks is TBD. ARP parameter assignments may be found at IANA. 363 4.1.1. Editor's notes 365 The hardware type is to be allocated by IANA prior to publication. 367 We could overload the Ethernet (1) or IEEE 802 (6) hardware type 368 value since 802.17 addresses are the same size and format as Ethernet 369 addresses. However, it is not inconceivable that overloading this 370 value may turn out to have unforeseen undesired consequences. As we 371 are not in any danger of running out of ARP hardware codes, we'll get 372 an 802.17-specific one. 374 4.2. IP Differentiated Service (DSCP) mapping to RPR 376 The Differentiated Service (DS) field of the IPv4 and IPv6 frame can 377 be used to convey service priority. The format of the IP DS field is 378 shown in Figure 1 below. 380 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 381 |-----------------------------------|-----------| 382 | DSCP | ECN | 383 |-----------------------------------|-----------| 385 Figure 1: Differentiated services field 387 The DSCP field denotes the differentiated services codepoint. The 388 DSCP is used to select the per hop behavior a packet experiences at 389 each network node. As per [6], [7], [8] and [9], the DSCP field 390 description is illustrated in Table 1. 392 |---------------------|----------|-------------------| 393 | IP Service Class | DSCP | Per Hop Behaviour | 394 |=====================|==========|===================| 395 | Standard | 000000 | Default Forwarding| 396 |---------------------|----------|-------------------| 397 | Low Priority Data | 001000 | Class Selector 1 | 398 |---------------------|----------|-------------------| 399 | High Throughput | 001010 | AF11 | 400 | Data | 001100 | AF12 | 401 | | 001110 | AF13 | 402 |---------------------|----------|-------------------| 403 | OAM | 010000 | Class Selector 2 | 404 |---------------------|----------|-------------------| 405 | | 010010 | AF21 | 406 | Low Latency Data | 010100 | AF22 | 407 | | 010110 | AF23 | 408 |---------------------|----------|-------------------| 409 | Broadcast Video | 011000 | Class Selector 3 | 410 |---------------------|----------|-------------------| 411 | Multimedia | 011010 | AF31 | 412 | Streaming | 011100 | AF32 | 413 | | 011110 | AF33 | 414 |---------------------|----------|-------------------| 415 |Real-time Interactive| 100000 | Class Selector 4 | 416 |---------------------|----------|-------------------| 417 | Multimedia | 100010 | AF41 | 418 | Conferencing | 100100 | AF42 | 419 | | 100110 | AF43 | 420 |---------------------|----------|-------------------| 421 | Signaling | 101000 | Class Selector 5 | 422 |---------------------|----------|-------------------| 423 | Telephony | 101110 | EF | 424 |---------------------|----------|-------------------| 425 | Network Control | 110000 | Class Selector 6 | 426 |---------------------|----------|-------------------| 427 | Reserved | 111000 | Class Selector 7 | 428 | for future use | | | 429 |---------------------|----------|-------------------| 431 Table 1: DSCP field definition 433 The best effort DSCP group denotes a best effort service. 435 The assured forwarding (AF) PHB groups are a means for a provider DS 436 domain to offer different levels of forwarding assurances for IP 437 packets received from a customer DS domain. In case of congestion, 438 the drop precedence of a packet determines the relative importance of 439 the packet within the AF class. A congested DS node tries to protect 440 packets with a lower drop precedence value from being lost by 441 preferably discarding packets with a higher drop precedence value. 443 The expedited forwarding (EF) PHB group is used to build a low loss, 444 low latency, low jitter, assured bandwidth, end-to-end service 445 through DS domains. 447 The class selector PHBs are to provide limited backwards capability 448 for IP precedence. 450 The mapping between IP DSCP to RPR header service class relevant 451 fields are shown in Table 2. This is the default mapping for 452 interoperablility, vendors/operators may choose to map differently. 453 Note that four treatment aggregates are used as suggested by [10]. 455 |----------|-------------------|-------------|-------------| 456 | DSCP | RPR | RPR | Traffic | 457 | | service_class | mark_fe | Allocation | 458 |==========|===================|=============|=============| 459 | 000000 | classC | ignore | EIR | 460 | 001000 | | | | 461 |----------|-------------------|-------------|-------------| 462 | 001010 | | FALSE | classB-CIR | 463 | | |-------------|-------------| 464 | 001100 | | TRUE | classB-EIR | 465 | 001110 | | | | 466 |----------| |-------------|-------------| 467 | 010000 | | FALSE | classB-CIR | 468 |----------| classB |-------------|-------------| 469 | 010010 | | FALSE | classB-CIR | 470 | | |-------------|-------------| 471 | 010100 | | TRUE | classB-EIR | 472 | 010110 | | | | 473 |----------| |-------------|-------------| 474 | 011010 | | FALSE | classB-CIR | 475 | | |-------------|-------------| 476 | 011100 | | TRUE | classB-EIR | 477 | 011110 | | | | 478 |----------|-------------------|-------------|-------------| 479 | 011000 | | | | 480 |----------| | | | 481 | 100000 | | | | 482 |----------| | | | 483 | 100010 | | | | 484 | 100100 | classA | ignore | CIR | 485 | 100110 | | | | 486 |----------| | | | 487 | 101000 | | | | 488 |----------| | | | 489 | 101110 | | | | 490 |----------|-------------------|-------------|-------------| 491 | | | | | 492 | 110000 | classA | ignore | CIR | 493 | | | | | 494 |----------|-------------------|-------------|-------------| 496 Table 2: IP DSCP to RPR Header Mapping 498 Services marked with a DF and CS1 DSCP only an EIR component. 500 Service marked with AF11, AF21, AF31 and CS2 DSCPs have an aggregated 501 CIR and services marked with AF12, AF13, AF22, AF23, AF32 and AF33 502 have an aggregated EIR component. 504 Traffic marked with CS6 DSCP class (routing control) also has only a 505 CIR component. Further, it is recommended that CS6 marked traffic be 506 assigned its own RPR service. These guidleines are provided so that 507 congestion from other traffic sources does not cause routing 508 instability since it is separated from the routing control traffic. 509 As CS7 is for future use, no mapping is provided. 511 classA traffic is not fairness eligible and classC traffic is 512 fairness eligible. For classB traffic the client may request a 513 specific treatment using the mark_fe parameter. For classA and 514 classC traffic any mark_fe request would be ignored. 516 As per [11], bits 6 and 7 of the DS field can be defined to be the 517 explicit congestion notification (ECN) field. The coding of the ECN 518 does not influence the mappings to the RPR service class relevant 519 fields (listed in Table 2). 521 5. IPv6 specific details 523 Transport of IPv6 packets over IEEE 802.17 networks is designed to be 524 as similar to IPv6 over Ethernet as possible. The intent is to 525 minimize time and risk in developing both the standard and the 526 implementations. 528 5.1. Stateless autoconfiguration 530 IPv6 stateless autoconfiguration follows the rules and procedures in 531 section 4 of RFC 2464 [5]. 533 5.2. Link local address 535 IPv6 link-local addresses follow the rules and procedures in section 536 5 of RFC 2464 [5]. 538 5.3. Unicast address mappings 540 IPv6 unicast address mappings follow the rules and procedures in 541 section 6 of RFC 2464 [5]. 543 5.4. Multicast address mappings 545 IPv6 multicast address mappings follow the rules and procedures in 546 section 7 of RFC 2464 [5]. 548 5.5. Diffserv mapping 550 The mapping is as specified in Section 4.2 552 6. MPLS specific details 554 Transport of MPLS packets over IEEE 802.17 follows RFC 3032 [12]. 556 6.1. MPLS EXP bit Mapping to RPR 558 MPLS support for DiffServ is defined in RFC 3270 [13]. The MPLS shim 559 header is illustrated in Figure 2 below. 561 | 20 | 3 | 1 | 8 | 562 |----------------------------|---------|-----|---------------| 563 | Label | EXP | S | TTL | 564 |----------------------------|---------|-----|---------------| 566 Figure 2: MPLS shim 568 The EXP bits define the PHB. However [12]does not recommend specific 569 EXP values for DiffServ PHB (e.g., EF, AF, DF). 571 6.1.1. MPLS EXP PHB mapping to RPR 573 The mapping between MPLS EXP bits to RPR header service class 574 relevant fields are shown in Table 3 for E-LSP. For L-LSP, only the 575 drop precedence is encoded in the EXP bits. This is the default 576 mapping for interoperablility, vendors/operators may choose to map 577 differently. Note that four treatment aggregates are used as 578 suggested by [10]. 580 |-------------|-------------------|-------------|-------------| 581 | MPLS | RPR | RPR | Traffic | 582 | EXP | service_class | mark_fe | Allocation | 583 |=============|===================|=============|=============| 584 | 000 | classC | ignore | EIR | 585 | 001 | | | | 586 |-------------|-------------------|-------------|-------------| 587 | 010 | | FALSE | classB-CIR | 588 | | classB |-------------|-------------| 589 | 011 | | TRUE | classB-EIR | 590 |-------------|-------------------|-------------|-------------| 591 | 100 | | | | 592 | | classA | ignore | CIR | 593 |101(reserved)| | | | 594 |-------------|-------------------|-------------|-------------| 595 | 110 | | | | 596 | | classA | ignore | CIR | 597 |111(reserved)| | | | 598 |-------------|-------------------|-------------|-------------| 600 Table 3: MPLS EXP to RPR header mapping 602 7. Security considerations 604 This specification provides no security measures. However, it should 605 be noted that all of these vulnerabilities exist today for transport 606 of IP and MPLS over Ethernet networks. In particular: 608 1. Masquerading and spoofing are possible. There is no strong 609 authentication. 611 2. Traffic analysis and snooping is possible since no encryption is 612 provided, either by this specification or by IEEE 802.17 614 3. Limited denial of service attacks are possible by, for example, 615 flooding the IEEE 802.17 network with ARP broadcasts. These 616 attacks are limited to other class-C (best effort) traffic. 618 4. Attacks against the IEEE 802.17 ring management protocols are 619 possible by stations that are directly connected to the ring. 621 8. IANA considerations 623 A new ARP codepoint is to be assigned by IANA per Section 4.1 625 9. Acknowledgements 627 The authors acknowledge and appreciate the work and comments of the 628 IETF IPoRPR working group and the IEEE 802.17 working group. 630 10. References 632 [1] Bradner, S., "Key words for use in RFCs to Indicate 633 Requirements Levels", RFC 2119, BCP 14, March 1997. 635 [2] "Resilient packet ring access method and physical Layer 636 specifications - medium access control parameters, physical 637 layer interface, and management parameters", IEEE 802.17-2004, 638 July 2004. 640 [3] Postel, J., "Internet Protocol", RFC 791, September 1981. 642 [4] Plummer, D., "An Ethernet Address Resolution Protocol", 643 RFC 826, November 1982. 645 [5] Crawford, ., "Transmission of IPv6 Packets over Ethernet 646 Networks", RFC 2464, December 1998. 648 [6] Nichols, K., "Definition of the Differentiated Services Field 649 (DS Field) in the IPv4 and IPv6 Headers.", RFC 2474, 650 December 1998. 652 [7] Heinanen, J., "Assured Forwarding PHB Group.", RFC 2597, 653 June 1999. 655 [8] Jacobson, V., "An Expedited Forwarding PHB Group.", RFC 2598, 656 June 1999. 658 [9] Babiarz, J., "Configuration Guidelines for Diffserv Service 659 Classes", RFC 4594, August 2006. 661 [10] Chan, K., "Aggregation of Diffserv Service Classes.", 662 draft-ietf-tsvwg-diffserv-class-aggr-00 (work in progress), 663 June 2006. 665 [11] Ramakrishnan, K., "The Addition of Explicit Congestion 666 Notification (ECN) to IP", RFC 3168, September 2001. 668 [12] Rosen, E., "MPLS Label Stack Encoding", RFC 3032, January 2001. 670 [13] Le Faucheur, F., "Multi-Protocol Label Switching (MPLS) Support 671 of Differentiated Services", RFC 3270, May 2002. 673 [14] "Media Access Control (MAC) Bridges - Amendment 1: Bridging of 674 802.17", IEEE 802.17a-2004, October 2004. 676 [15] "Resilient Packet Ring Access Method and Physical Layer 677 Specifications - Amendment 1: Spatially Aware Sublayer", 678 IEEE P802.17b. 680 Authors' Addresses 682 Marc Holness 683 Nortel 684 3500 Carling Avenue 685 Ottawa, ON K2H 8E9 686 CA 688 Phone: +1 613 765 2840 689 Email: holness@nortel.com 691 Glenn Parsons 692 Nortel 693 3500 Carling Avenue 694 Ottawa, ON K2H 8E9 695 CA 697 Phone: +1 613 763 7582 698 Email: gparsons@nortel.com 700 Full Copyright Statement 702 Copyright (C) The Internet Society (2006). 704 This document is subject to the rights, licenses and restrictions 705 contained in BCP 78, and except as set forth therein, the authors 706 retain all their rights. 708 This document and the information contained herein are provided on an 709 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 710 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 711 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 712 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 713 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 714 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 716 Intellectual Property 718 The IETF takes no position regarding the validity or scope of any 719 Intellectual Property Rights or other rights that might be claimed to 720 pertain to the implementation or use of the technology described in 721 this document or the extent to which any license under such rights 722 might or might not be available; nor does it represent that it has 723 made any independent effort to identify any such rights. Information 724 on the procedures with respect to rights in RFC documents can be 725 found in BCP 78 and BCP 79. 727 Copies of IPR disclosures made to the IETF Secretariat and any 728 assurances of licenses to be made available, or the result of an 729 attempt made to obtain a general license or permission for the use of 730 such proprietary rights by implementers or users of this 731 specification can be obtained from the IETF on-line IPR repository at 732 http://www.ietf.org/ipr. 734 The IETF invites any interested party to bring to its attention any 735 copyrights, patents or patent applications, or other proprietary 736 rights that may cover technology that may be required to implement 737 this standard. Please address the information to the IETF at 738 ietf-ipr@ietf.org. 740 Acknowledgment 742 Funding for the RFC Editor function is provided by the IETF 743 Administrative Support Activity (IASA).