[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

IPoRPR Working Group                                          M. Holness
Internet-Draft                                                G. Parsons
Intended status: Standards Track                                  Nortel
Expires: February 22, 2007                               August 21, 2006


  Mapping of IP/MPLS packets into IEEE 802.17 (Resilient packet ring)
                                Networks
                     draft-ietf-iporpr-basic-03.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February 22, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).













Holness & Parsons       Expires February 22, 2007               [Page 1]


Internet-Draft                   IPoRPR                      August 2006


Abstract

   This document specifies a basic standard method of encapsulating
   IPv4, IPv6, and MPLS datagrams into IEEE 802.17 Resilient packet ring
   (RPR) datagrams.














































Holness & Parsons       Expires February 22, 2007               [Page 2]


Internet-Draft                   IPoRPR                      August 2006


Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

   The term "Higher Layer" refers to IPv4, IPv6, and MPLS when they act
   as clients of the IEEE 802.17 network.

   "IP" refers to both IPv4 and IPv6.  The terms "IPv4" and "IPv6" are
   used only when a specific version of IP is meant.








































Holness & Parsons       Expires February 22, 2007               [Page 3]


Internet-Draft                   IPoRPR                      August 2006


1.  Introduction

   This document gives a definition of how to transport IP/MPLS over
   IEEE 802.17 RPR in "basic mode".  In basic mode, higher layers do not
   have any control over the underlying network and treat it as a
   broadcast media.  This document will describe all the necessary
   mappings to aid interoperable networks.  This includes encapsulation
   formats (e.g., IPv4/IPv6), how to perform address resolution (e.g.,
   ARP/ND), IP multicast transmission, and priority mapping to the RPR
   service class.









































Holness & Parsons       Expires February 22, 2007               [Page 4]


Internet-Draft                   IPoRPR                      August 2006


2.  IEEE 802.17

   This section gives a brief introduction to the IEEE 802.17 protocol.
   The intent is to provide information needed to understand the rest of
   this document.  This section SHALL NOT be used as a definitive
   description of IEEE 802.17 [2] or amendments IEEE 802.17a [14], and
   IEEE 802.17b [15].

   IEEE 802.17 SHALL be consulted for specific details on the
   functionality.  Clause 5 of 802.17 contains a ~30 page overview of
   the ~700 page specification.  Details on the MAC service is contained
   in Clause 6 of 802.17.

2.1.  Overview of IEEE 802.17

   IEEE 802.17 is a dual, counter-rotating, ring network technology with
   destination stripping.  In the event of a fault (such as a fiber cut)
   the stations on each side of the fault can continue to function by
   wrapping the ring and/or by steering away from the fault and towards
   the operational path.

   The ring is composed of two ringlets, called ringlet0 and ringlet1.

   A station may transmit a frame in either direction around the ring.
   IEEE 802.17 includes MAC-level protocols to determine the default
   path to each destination.  The determination of default may be by any
   algorithm, including shortest path.  Normally, the 802.17 MAC layer
   will automatically send frames via the default path.  Alternatively,
   higher layers (such as IP) may explicitly specify the ringlet to use.

   All stations on the ring have 48-bit IEEE 802 addresses.

   IEEE 802.17 is a media-independent network protocol that is layered
   over several different physical media.  SONET/SDH, Gigabit Ethernet
   and 10-Gigabit Ethernet are currently specified.  The higher layers
   are shielded from any media dependencies.

   There are three service classes: classA provides committed bandwidth
   and low delay and jitter, classB has committed and excess bandwidth
   components and bounded delay and jitter, and classC is best-effort.

   There are several frame types, one of which is a data frame.  The
   data frame contains a payload (such as an IPv4, IPv6, or MPLS
   packet).  The type of the payload is indicated by a 2-byte type
   field.  The type-field is identical to the type field in IEEE 802.3
   Ethernet.

   There is a TTL in the IEEE 802.17 frame headers.  This TTL is used to



Holness & Parsons       Expires February 22, 2007               [Page 5]


Internet-Draft                   IPoRPR                      August 2006


   measure and limit the lifetime of frames on a ring.

2.2.  IEEE 802.17 MAC service

   The IEEE 802.17 MAC service definition defines the MA_DATA.request
   primitive which a station uses to transmit data (see section 6.4.1 of
   [2]).  This primitive takes several parameters (only three of which,
   noted with '*', are mandatory):

      *destination_address

      source_address

      *mac_service_data_unit

      frame_check_sequence

      *service_class

      ringlet_id

      mac_protection

      mark_fe

      strict_order

      destination_address_extended

      source_address_extended

      flooding_form

2.2.1.  IEEE 802.17 addressing

   The destination address (DA) [destination_address] is the 48-bit MAC
   address of the destination station.  This may also be a multicast or
   broadcast address.  This is a required parameter.

   The source address (SA) [source_address] is the 48-bit MAC address of
   the source station.  This is an optional parameter.  If it is
   omitted, the MAC uses the source address that is assigned to the
   station.

2.2.2.  IEEE 802.17 payload

   The MAC SDU [mac_service_data_unit] is the RPR payload.  It includes
   the entire IP/MPLS packet prefaced with the protocol type field.



Holness & Parsons       Expires February 22, 2007               [Page 6]


Internet-Draft                   IPoRPR                      August 2006


   This is a required parameter.

2.2.3.  IEEE 802.17 service Classes

   One of the key features of RPR that can distinguish it from other
   network interconnects, is it ability to support multiple service
   qualities.  Per service quality flow control protocols regulate
   traffic introduced by clients.  The list of supported service classes
   are listed below:

   classA:   classA service provides an allocated, guaranteed data rate,
             and low end-to-end delay and jitter bound. classA traffic
             is allocated with a committed information rate (CIR).
             Traffic above the allocated rate is rejected. classA
             traffic has precedence over classB and classC traffic at
             the ingress to the ring and in transit.  This class is well
             suited for real time applications.

   classB:   classB service provides an allocated, guaranteed data rate,
             and bounded end-to-end delay and jitter for the traffic
             within the allocated rate. classB also provides access to
             additional best effort data transmission that is not
             allocated, guaranteed, or bounded. classB traffic is
             allocated with a CIR component.  Any classB traffic amount
             beyond the allocated CIR is referred to as excess
             information rate (EIR) classB traffic. classB traffic
             (including classB-EIR) has precedence over classC traffic
             at the ingress to the ring.

   classC:   classC service provides a best-effort traffic service with
             non allocated or guaranteed data rate, and no bounds on
             end-to-end delay or jitter. classC traffic has the lowest
             precedence for ingress to the ring.  Both classB-EIR and
             classC traffic is governed by the RPR fairness algorithm
             which ensures proper partitioning of opportunistic traffic
             over the ring.  This class is well suited for best effort
             applications.

   Internal to the RPR MAC, classA traffic is partitioned into two sub
   classes: subclassA0 and subclassA1.  This partitioning is done in
   order to increase the ability of the ring to reclaim unused classA
   traffic.  The RPR MAC is configured for a total classA amount, from
   which it determines how much is subclassA0 and subclassA1.  The
   division of classA is based on ring circumference and the size of
   internal transit queues.  The reclaimable bandwidth allocated to
   subclassA1 can be reclaimed by traffic of classB-EIR and classC when
   not being used by the station originating the classA traffic being
   reclaimed.  Note that subclassA0 is not reclaimable, i.e. this



Holness & Parsons       Expires February 22, 2007               [Page 7]


Internet-Draft                   IPoRPR                      August 2006


   bandwidth is reserved and not available for classB or classC traffic.

   The RPR datagram carries the priority (i.e., service class) of the
   traffic being transported within a sc (service class) field found
   within the baseControl field of the RPR header.

2.2.4.  IEEE 802.17 fairness

   The RPR fairness algorithm ensures proper partitioning of
   opportunistic traffic over the ring and governs classB-EIR and classC
   traffic.  The mark_fe parameter indicate a request to mark and treat
   a frame as fairness eligible regardless of how it would have been
   marked or treated otherwise.  This guides the MAC entity on how to
   set the fe (fairness eligible) field.

   The RPR datagram conveys the application of the fairness algorithm on
   the datagram by the value of the fairness eligible (fe) field, found
   in the baseControl field of the RPR header.

































Holness & Parsons       Expires February 22, 2007               [Page 8]


Internet-Draft                   IPoRPR                      August 2006


3.  General mapping details

   This section covers issues that are common to IPv4, IPv6, and MPLS.

3.1.  IEEE 802.17 MAC service parameters

   When transmitting an IP or MPLS packet, a host or router indicates
   various parameters to the IEEE 802.17 MAC layer (see section 6.4 of
   [2]).  This section specifies how those parameters are to be used.

3.1.1.  Destination_address

   Is the 48-bit MAC address of the 802.17 station to which the packet
   is being transmitted.

3.1.2.  Source_address

   The source_address SHOULD be the address assigned to the station that
   is transmitting the packet.  Per [2] if the client omits this
   parameter then the MAC inserts the correct address.

3.1.3.  mac_service_data_unit

   This is the payload, including the protocol type field.  See
   "Protocol Type Field" (Section 3.2), for more information.

3.1.4.   frame_check_sequence

   The MAC will calculate the FCS

3.1.5.   serviceClass

   Specific service class mapping from DSCP and EXP within the client
   payload SHOULD be used to determine the RPR service class.  These
   mappings are shown in Section 4.2 and Section 6.1.

3.1.6.   ringlet_id

   The client SHOULD NOT specify the ringletID.  The MAC will use its
   default algorithm to select a ringlet.

3.1.7.   mac_protection

   This parameter SHOULD NOT be specified.  The IEEE 802.17 MAC will
   then use its default treatment






Holness & Parsons       Expires February 22, 2007               [Page 9]


Internet-Draft                   IPoRPR                      August 2006


3.1.8.   mark_fe

   This parameter SHOULD NOT be specified unless the RPR service class
   is CLASS B as indicated from the mappings in Section 4.2 and
   Section 6.1.

3.1.9.   strict_order

   This parameter SHOULD NOT be specified.  The IEEE 802.17 MAC will
   then use its default treatment.

3.1.10.   destination_address_extended

   This parameter SHOULD NOT be specified.  The IEEE 802.17 MAC will
   populate if necessary.

3.1.11.   source_address_extended

   This parameter SHOULD NOT be specified.  The IEEE 802.17 MAC will
   populate if necessary.

3.1.12.  flooding_form

   This parameter SHOULD NOT be specified.  The IEEE 802.17 MAC will
   populate if necessary.

3.2.  Protocol Type Field

   The 16-bit protocol type field (or Ethertype) is set to a value to
   indicate the payload protocol.  The values for IPv4, IPv6, and MPLS
   are:

      0x0800 If the payload contains an IPv4 packet.

      0x0806 If the payload contains an ARP packet.

      0x86DD If the payload contains an IPv6 packet.

      0x8847 If the payload contains a MPLS Unicast packet.

      0x8848 if the payload contains a MPLS Multicast packet.

3.3.  Payload

   The payload contains the IPv4, IPv6, or MPLS packet.  The first byte
   of the IPv4 header, IPv6 header, or top MPLS label begins immediately
   after the 802.17 header.




Holness & Parsons       Expires February 22, 2007              [Page 10]


Internet-Draft                   IPoRPR                      August 2006


   Note that in 802.17 there is no minimum size for frames carried over
   Ethernet physical layers, thus there is no need to pad frames that
   are shorter than the minimum size.  However, the robustness principle
   dictates that nodes be able to handle frames that are padded.

   Like 802.3 Ethernet, 802.17 defines the maximum regular frame payload
   as 1500 bytes.  Note that a maximum jumbo frame payload size that MAY
   be supported is defined at 9100 bytes.

3.4.  Byte Order

   As described in "APPENDIX B: Data Transmission Order" of RFC 791 [3],
   IP and MPLS datagrams are transmitted over the IEEE 802.17 network as
   a series of 8-bit bytes in "big endian" order.  This is the same byte
   order as used for Ethernet.

3.5.  Ringlet Selection

   IEEE 802.17 allows the higher layer to select the direction around
   the ring that traffic is to go.  If the higher layer does not make
   the selection then the IEEE 802.17 MAC makes the decision.  For basic
   mode ringlet selection is left to the MAC.

3.6.  Higher layer TTL and ring TTL

   There is no correlation or interaction between the higher layer TTL
   and the IEEE 802.17 TTL.
























Holness & Parsons       Expires February 22, 2007              [Page 11]


Internet-Draft                   IPoRPR                      August 2006


4.  IPv4 specific mapping details

4.1.  Address resolution

   ARP [4] is used to map IPv4 addresses to the appropriate MAC address.
   The "Hardware Address Space" parameter (ar$hrd) used for IEEE 802.17
   networks is TBD.  ARP parameter assignments may be found at IANA.

4.1.1.  Editor's notes

   The hardware type is to be allocated by IANA prior to publication.

   We could overload the Ethernet (1) or IEEE 802 (6) hardware type
   value since 802.17 addresses are the same size and format as Ethernet
   addresses.  However, it is not inconceivable that overloading this
   value may turn out to have unforeseen undesired consequences.  As we
   are not in any danger of running out of ARP hardware codes, we'll get
   an 802.17-specific one.

4.2.  IP Differentiated Service (DSCP) mapping to RPR

   The Differentiated Service (DS) field of the IPv4 and IPv6 frame can
   be used to convey service priority.  The format of the IP DS field is
   shown in Figure 1 below.

      |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
      |-----------------------------------|-----------|
      |               DSCP                |    ECN    |
      |-----------------------------------|-----------|

   Figure 1: Differentiated services field

   The DSCP field denotes the differentiated services codepoint.  The
   DSCP is used to select the per hop behavior a packet experiences at
   each network node.  As per [6], [7], [8] and [9], the DSCP field
   description is illustrated in Table 1.















Holness & Parsons       Expires February 22, 2007              [Page 12]


Internet-Draft                   IPoRPR                      August 2006


       |---------------------|----------|-------------------|
       |  IP Service Class   |   DSCP   | Per Hop Behaviour |
       |=====================|==========|===================|
       |      Standard       |  000000  | Default Forwarding|
       |---------------------|----------|-------------------|
       |  Low Priority Data  |  001000  | Class Selector 1  |
       |---------------------|----------|-------------------|
       |   High Throughput   |  001010  |      AF11         |
       |        Data         |  001100  |      AF12         |
       |                     |  001110  |      AF13         |
       |---------------------|----------|-------------------|
       |        OAM          |  010000  | Class Selector 2  |
       |---------------------|----------|-------------------|
       |                     |  010010  |      AF21         |
       |  Low Latency Data   |  010100  |      AF22         |
       |                     |  010110  |      AF23         |
       |---------------------|----------|-------------------|
       |  Broadcast Video    |  011000  | Class Selector 3  |
       |---------------------|----------|-------------------|
       |    Multimedia       |  011010  |      AF31         |
       |      Streaming      |  011100  |      AF32         |
       |                     |  011110  |      AF33         |
       |---------------------|----------|-------------------|
       |Real-time Interactive|  100000  | Class Selector 4  |
       |---------------------|----------|-------------------|
       |    Multimedia       |  100010  |      AF41         |
       |    Conferencing     |  100100  |      AF42         |
       |                     |  100110  |      AF43         |
       |---------------------|----------|-------------------|
       |    Signaling        |  101000  | Class Selector 5  |
       |---------------------|----------|-------------------|
       |    Telephony        |  101110  |      EF           |
       |---------------------|----------|-------------------|
       |   Network Control   |  110000  | Class Selector 6  |
       |---------------------|----------|-------------------|
       |       Reserved      |  111000  | Class Selector 7  |
       |    for future use   |          |                   |
       |---------------------|----------|-------------------|

   Table 1: DSCP field definition

   The best effort DSCP group denotes a best effort service.

   The assured forwarding (AF) PHB groups are a means for a provider DS
   domain to offer different levels of forwarding assurances for IP
   packets received from a customer DS domain.  In case of congestion,
   the drop precedence of a packet determines the relative importance of
   the packet within the AF class.  A congested DS node tries to protect



Holness & Parsons       Expires February 22, 2007              [Page 13]


Internet-Draft                   IPoRPR                      August 2006


   packets with a lower drop precedence value from being lost by
   preferably discarding packets with a higher drop precedence value.

   The expedited forwarding (EF) PHB group is used to build a low loss,
   low latency, low jitter, assured bandwidth, end-to-end service
   through DS domains.

   The class selector PHBs are to provide limited backwards capability
   for IP precedence.

   The mapping between IP DSCP to RPR header service class relevant
   fields are shown in Table 2.  This is the default mapping for
   interoperablility, vendors/operators may choose to map differently.
   Note that four treatment aggregates are used as suggested by [10].





































Holness & Parsons       Expires February 22, 2007              [Page 14]


Internet-Draft                   IPoRPR                      August 2006


       |----------|-------------------|-------------|-------------|
       |   DSCP   |        RPR        |     RPR     |  Traffic    |
       |          |   service_class   |   mark_fe   | Allocation  |
       |==========|===================|=============|=============|
       |  000000  |      classC       |   ignore    |     EIR     |
       |  001000  |                   |             |             |
       |----------|-------------------|-------------|-------------|
       |  001010  |                   |    FALSE    | classB-CIR  |
       |          |                   |-------------|-------------|
       |  001100  |                   |    TRUE     | classB-EIR  |
       |  001110  |                   |             |             |
       |----------|                   |-------------|-------------|
       |  010000  |                   |    FALSE    | classB-CIR  |
       |----------|      classB       |-------------|-------------|
       |  010010  |                   |    FALSE    | classB-CIR  |
       |          |                   |-------------|-------------|
       |  010100  |                   |    TRUE     | classB-EIR  |
       |  010110  |                   |             |             |
       |----------|                   |-------------|-------------|
       |  011010  |                   |    FALSE    | classB-CIR  |
       |          |                   |-------------|-------------|
       |  011100  |                   |    TRUE     | classB-EIR  |
       |  011110  |                   |             |             |
       |----------|-------------------|-------------|-------------|
       |  011000  |                   |             |             |
       |----------|                   |             |             |
       |  100000  |                   |             |             |
       |----------|                   |             |             |
       |  100010  |                   |             |             |
       |  100100  |      classA       |   ignore    |     CIR     |
       |  100110  |                   |             |             |
       |----------|                   |             |             |
       |  101000  |                   |             |             |
       |----------|                   |             |             |
       |  101110  |                   |             |             |
       |----------|-------------------|-------------|-------------|
       |          |                   |             |             |
       |  110000  |      classA       |   ignore    |     CIR     |
       |          |                   |             |             |
       |----------|-------------------|-------------|-------------|

   Table 2: IP DSCP to RPR Header Mapping

   Services marked with a DF and CS1 DSCP only an EIR component.

   Service marked with AF11, AF21, AF31 and CS2 DSCPs have an aggregated
   CIR and services marked with AF12, AF13, AF22, AF23, AF32 and AF33
   have an aggregated EIR component.



Holness & Parsons       Expires February 22, 2007              [Page 15]


Internet-Draft                   IPoRPR                      August 2006


   Traffic marked with CS6 DSCP class (routing control) also has only a
   CIR component.  Further, it is recommended that CS6 marked traffic be
   assigned its own RPR service.  These guidleines are provided so that
   congestion from other traffic sources does not cause routing
   instability since it is separated from the routing control traffic.
   As CS7 is for future use, no mapping is provided.

   classA traffic is not fairness eligible and classC traffic is
   fairness eligible.  For classB traffic the client may request a
   specific treatment using the mark_fe parameter.  For classA and
   classC traffic any mark_fe request would be ignored.

   As per [11], bits 6 and 7 of the DS field can be defined to be the
   explicit congestion notification (ECN) field.  The coding of the ECN
   does not influence the mappings to the RPR service class relevant
   fields (listed in Table 2).



































Holness & Parsons       Expires February 22, 2007              [Page 16]


Internet-Draft                   IPoRPR                      August 2006


5.  IPv6 specific details

   Transport of IPv6 packets over IEEE 802.17 networks is designed to be
   as similar to IPv6 over Ethernet as possible.  The intent is to
   minimize time and risk in developing both the standard and the
   implementations.

5.1.  Stateless autoconfiguration

   IPv6 stateless autoconfiguration follows the rules and procedures in
   section 4 of RFC 2464 [5].

5.2.  Link local address

   IPv6 link-local addresses follow the rules and procedures in section
   5 of RFC 2464 [5].

5.3.  Unicast address mappings

   IPv6 unicast address mappings follow the rules and procedures in
   section 6 of RFC 2464 [5].

5.4.  Multicast address mappings

   IPv6 multicast address mappings follow the rules and procedures in
   section 7 of RFC 2464 [5].

5.5.  Diffserv mapping

   The mapping is as specified in Section 4.2





















Holness & Parsons       Expires February 22, 2007              [Page 17]


Internet-Draft                   IPoRPR                      August 2006


6.  MPLS specific details

   Transport of MPLS packets over IEEE 802.17 follows RFC 3032 [12].

6.1.  MPLS EXP bit Mapping to RPR

   MPLS support for DiffServ is defined in RFC 3270 [13].  The MPLS shim
   header is illustrated in Figure 2 below.

         |             20             |    3    |  1  |       8       |
         |----------------------------|---------|-----|---------------|
         |            Label           |   EXP   |  S  |      TTL      |
         |----------------------------|---------|-----|---------------|

   Figure 2: MPLS shim

   The EXP bits define the PHB.  However [12]does not recommend specific
   EXP values for DiffServ PHB (e.g., EF, AF, DF).

6.1.1.  MPLS EXP PHB mapping to RPR

   The mapping between MPLS EXP bits to RPR header service class
   relevant fields are shown in Table 3 for E-LSP.  For L-LSP, only the
   drop precedence is encoded in the EXP bits.  This is the default
   mapping for interoperablility, vendors/operators may choose to map
   differently.  Note that four treatment aggregates are used as
   suggested by [10].
























Holness & Parsons       Expires February 22, 2007              [Page 18]


Internet-Draft                   IPoRPR                      August 2006


       |-------------|-------------------|-------------|-------------|
       |     MPLS    |        RPR        |     RPR     |  Traffic    |
       |     EXP     |   service_class   |   mark_fe   | Allocation  |
       |=============|===================|=============|=============|
       |     000     |      classC       |   ignore    |     EIR     |
       |     001     |                   |             |             |
       |-------------|-------------------|-------------|-------------|
       |     010     |                   |    FALSE    | classB-CIR  |
       |             |      classB       |-------------|-------------|
       |     011     |                   |    TRUE     | classB-EIR  |
       |-------------|-------------------|-------------|-------------|
       |     100     |                   |             |             |
       |             |      classA       |   ignore    |     CIR     |
       |101(reserved)|                   |             |             |
       |-------------|-------------------|-------------|-------------|
       |     110     |                   |             |             |
       |             |      classA       |   ignore    |     CIR     |
       |111(reserved)|                   |             |             |
       |-------------|-------------------|-------------|-------------|

   Table 3: MPLS EXP to RPR header mapping






























Holness & Parsons       Expires February 22, 2007              [Page 19]


Internet-Draft                   IPoRPR                      August 2006


7.  Security considerations

   This specification provides no security measures.  However, it should
   be noted that all of these vulnerabilities exist today for transport
   of IP and MPLS over Ethernet networks.  In particular:

   1.  Masquerading and spoofing are possible.  There is no strong
       authentication.

   2.  Traffic analysis and snooping is possible since no encryption is
       provided, either by this specification or by IEEE 802.17

   3.  Limited denial of service attacks are possible by, for example,
       flooding the IEEE 802.17 network with ARP broadcasts.  These
       attacks are limited to other class-C (best effort) traffic.

   4.  Attacks against the IEEE 802.17 ring management protocols are
       possible by stations that are directly connected to the ring.

































Holness & Parsons       Expires February 22, 2007              [Page 20]


Internet-Draft                   IPoRPR                      August 2006


8.  IANA considerations

   A new ARP codepoint is to be assigned by IANA per Section 4.1
















































Holness & Parsons       Expires February 22, 2007              [Page 21]


Internet-Draft                   IPoRPR                      August 2006


9.  Acknowledgements

   The authors acknowledge and appreciate the work and comments of the
   IETF IPoRPR working group and the IEEE 802.17 working group.















































Holness & Parsons       Expires February 22, 2007              [Page 22]


Internet-Draft                   IPoRPR                      August 2006


10.  References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate
         Requirements Levels", RFC 2119, BCP 14, March 1997.

   [2]   "Resilient packet ring access method and physical Layer
         specifications - medium access control parameters, physical
         layer interface, and management parameters", IEEE 802.17-2004,
         July 2004.

   [3]   Postel, J., "Internet Protocol", RFC 791, September 1981.

   [4]   Plummer, D., "An Ethernet Address Resolution Protocol",
         RFC 826, November 1982.

   [5]   Crawford, ., "Transmission of IPv6 Packets over Ethernet
         Networks", RFC 2464, December 1998.

   [6]   Nichols, K., "Definition of the Differentiated Services Field
         (DS Field) in the IPv4 and IPv6 Headers.", RFC 2474,
         December 1998.

   [7]   Heinanen, J., "Assured Forwarding PHB Group.", RFC 2597,
         June 1999.

   [8]   Jacobson, V., "An Expedited Forwarding PHB Group.", RFC 2598,
         June 1999.

   [9]   Babiarz, J., "Configuration Guidelines for Diffserv Service
         Classes", RFC 4594, August 2006.

   [10]  Chan, K., "Aggregation of Diffserv Service Classes.",
         draft-ietf-tsvwg-diffserv-class-aggr-00 (work in progress),
         June 2006.

   [11]  Ramakrishnan, K., "The Addition of Explicit Congestion
         Notification (ECN) to IP", RFC 3168, September 2001.

   [12]  Rosen, E., "MPLS Label Stack Encoding", RFC 3032, January 2001.

   [13]  Le Faucheur, F., "Multi-Protocol Label Switching (MPLS) Support
         of Differentiated Services", RFC 3270, May 2002.

   [14]  "Media Access Control (MAC) Bridges - Amendment 1: Bridging of
         802.17", IEEE 802.17a-2004, October 2004.

   [15]  "Resilient Packet Ring Access Method and Physical Layer
         Specifications - Amendment 1: Spatially Aware Sublayer",



Holness & Parsons       Expires February 22, 2007              [Page 23]


Internet-Draft                   IPoRPR                      August 2006


         IEEE P802.17b.


















































Holness & Parsons       Expires February 22, 2007              [Page 24]


Internet-Draft                   IPoRPR                      August 2006


Authors' Addresses

   Marc Holness
   Nortel
   3500 Carling Avenue
   Ottawa, ON  K2H 8E9
   CA

   Phone: +1 613 765 2840
   Email: holness@nortel.com


   Glenn Parsons
   Nortel
   3500 Carling Avenue
   Ottawa, ON  K2H 8E9
   CA

   Phone: +1 613 763 7582
   Email: gparsons@nortel.com































Holness & Parsons       Expires February 22, 2007              [Page 25]


Internet-Draft                   IPoRPR                      August 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Holness & Parsons       Expires February 22, 2007              [Page 26]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/