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

Versions: 00

     IP Over Resilient Packet Rings                        Kastenholz, Frank
     Internet Draft                                         Juniper Networks
     Document <draft-ietf-iporpr-core-00.txt>                  December 2002
     Category: Standards Track
     
     
       A Core Standard For Transmission of IP Packets Over IEEE 802.17
                      (Resilient Packet Ring) Networks
     
     
     Status of this Memo
     
        This document is an Internet-Draft and is in full conformance
        with all provisions of Section 10 of RFC2026.
     
        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.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Kastenholz       Standards Track - Expires June 2003             1
     
                         IP Over Resilient Packet Rings   December 2002
     
     
     
     Table of Contents
        1 Abstract...................................................2
        2 Change Log.................................................2
        3 Conventions used in this document..........................3
        4 Overview of IEEE 802.17....................................3
        5 General....................................................5
         5.1  IEEE 802.17 MAC Service Parameters.....................6
         5.2  Protocol Type Field....................................6
         5.3  Payload................................................7
         5.4  Byte Order.............................................7
         5.5  Trailer Format.........................................7
         5.6  Ringlet and Direction Selection........................7
         5.7  Higher Layer TTL and Ring TTL..........................7
        6 IPv4 Specific Details......................................8
         6.1  Address Resolution.....................................8
        7 IPv6 Specific Details......................................8
         7.1  Stateless Autoconfiguration............................8
         7.2  Link Local Address.....................................8
         7.3  Unicast Address Mappings...............................8
         7.4  Multicast Address Mappings.............................9
        8 MPLS Specific Details......................................9
        9 Security Considerations....................................9
        10 IANA Considerations........................................9
        11 References.................................................9
        12 Author's Addresses........................................10
     
     
     
     1  Abstract
     
        This memo specifies a standard method of encapsulating IPv4,
        IPv6, and MPLS datagrams for transmission over IEEE 802.17
        Resilient Packet Ring (RPR) Networks.  This method uses a
        minimum of IEEE 802.17 functions and capabilities.  The 802.17
        network is treated as a simple, flat network, similar in many
        ways to an Ethernet.
     
        A later specification will build upon this standard.  It will
        make more of the features and capabilities of IEEE 802.17
        networks available to IP and MPLS and specify the techniques to
        use those features.
     
     
     2  Change Log
     
        This section shall be removed prior to publication as an RFC.
     
     Kastenholz       Standards Track - Expires June 2003             2
     
     
                         IP Over Resilient Packet Rings   December 2002
     
        Version 00
     
        1. 802.17 path selection is not necessarily "shortest" --
           change overview to reflect this.
     
        2. The TTL and frame type are set by the MAC, not the client
     
        3. We specify that a new ARP hardware type code be used
     
        4. Note that DoS attacks are limited only to other class-C
           traffic
     
        5. Use 'ringlet' when we mean one of the two parts that make up
           the ring.
     
        6. Deleted unneeded text on padding from the Payload section
           (section 5.3) as 802.17 does not do minimum frame sizes.
           Included text that says that nodes should be able to handle
           padded frames, should they happen by.
     
        7. Stated that DSCP mappings are to be left to a later spec.
     
        8. Deleted the 802.17 packet-format stuff and replaced it with
           a description of the parameters of the MA_DATA.request MAC
           service primitive, and then how the parameters should be
           used for IP/MPLS.
     
        9. Deleted MTU comments. Just wasn't relevant.
     
        10.            Several editorial changes, not mentioned.
     
     
     3  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.
     
     
     4  Overview of IEEE 802.17
     
        This section gives a brief overview of the IEEE 802.17
        protocol.  The intent is to provide information needed to make
     
     
     Kastenholz       Standards Track - Expires June 2003             3
     
     
                         IP Over Resilient Packet Rings   December 2002
     
        sense of the rest of this note.  This section is NOT intended
        to be a technically rigorous description 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.
        When the fault clears, the ring reverts to normal operation.
     
        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 "best" path to each destination.  The determination of
        "best" may be by any of several algorithms, including shortest
        path.  Normally, the 802.17 MAC layer will automatically send
        frames via the "best" 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; others may be specified in the future.  The higher
        layers are shielded from any media dependencies.
     
        There are fairness and bandwidth-management elements.  There
        are three service classes: Class A provides low delay and low
        delay variation, class B has committed and excess bandwidth
        components, and class C is best-effort.  Except for best-
        efforts traffic, use of these features by IP and MPLS is beyond
        the scope of this specification.  Their use will be specified
        in a later document.
     
        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
        Ethernet.
     
        There is a TTL in the IEEE 802.17 frame headers.  This TTL is
        used to prevent frames from infinitely looping.
     
        The IEEE 802.17 MAC Service Definition defines the
        MA_DATA.request primitive which a station uses to transmit data
        (see section 5.3.1 of [7]).  This primitive takes several
        parameters:
     
     
     
     Kastenholz       Standards Track - Expires June 2003             4
     
     
                         IP Over Resilient Packet Rings   December 2002
     
          destinationAddress
               Is the 48-bit MAC address of the destination station.
               This may be a multicast or broadcast address.  This
               address is an IEEE 802 address.
     
               This is a required parameter.
     
          sourceAddress
               Is the 48-bit MAC address of the source station.  This
               address is an IEEE 802 address.
     
               This is an optional parameter.  If it is omitted, the
               MAC uses the source address that is assigned to the
               station.
     
          mSDU
               This is the payload, including the Ethernet type field.
     
               This is a required parameter.
     
          serviceClass
               Identifies the class of service that the frame gets.
               There are three classes: Class A which provides low
               delay and low delay variation.  Class B which has
               committed and excess bandwidth components, and class C
               is best-effort.
     
               This is a required parameter.
     
          ringletID
               Identifies which ringlet the frame is to be transmitted
               on.
     
               This is an optional parameter. If the parameter is not
               specified then the MAC uses its default algorithm to
               select a ringlet.
     
          markFE
               Indicates whether a class-B frame is subject to the IEEE
               IEEE 802.17 fairness algorithm or not.
     
               This is an optional parameter. If the parameter is not
               specified then the MAC uses its default algorithm.
     
     
     5  General
     
        This section covers issues that are common to IPv4, IPv6, and
        MPLS.
     
     
     
     
     Kastenholz       Standards Track - Expires June 2003             5
     
     
                         IP Over Resilient Packet Rings   December 2002
     
     5.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 5.3.1.1 of [7].  This section specifies how those
        parameters are to be used:
     
          destinationAddress
               Is the 48-bit MAC address of the 802.17 station to which
               the packet is being transmitted.
     
          sourceAddress
               The sourceAddress SHOULD be the address assigned to the
               station that is transmitting the packet. Per [7] if the
               client omits this parameter then the MAC inserts the
               correct address.
     
          mSDU
               This is the payload, including the Ethernet type field.
               See section 5.2, "Protocol Type Field", for more
               information.
     
          serviceClass
               The Service Class SHOULD be CLASS C, which ôprovides a
               best-effort traffic service with no allocated or
               guaranteed data rate and no bounds on end-to-end delay
               or jitterö.  The use of different service classes and,
               in particular, the mapping of DSCPs to service classes,
               is left for a later specification.
     
          ringletID
               The client SHOULD NOT specify the ringletID.  The MAC
               will use its default algorithm to select a ringlet.
     
          markFE
               This parameter is irrelevant since all packets sent in
               accordance with this protocol are Class C and markFE
               applies only to Class B traffic. However, for
               completeness, this parameter SHOULD NOT be specified.
               The IEEE 802.17 MAC will then use its default treatment.
     
     
     5.2 Protocol Type Field
     
        The 16-bit protocol type field is set to a value to indicate
        the payloadÆs 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, or
     
     Kastenholz       Standards Track - Expires June 2003             6
     
     
                         IP Over Resilient Packet Rings   December 2002
     
        0x8848  if the payload contains a MPLS Multicast packet.
     
     
     5.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 headers.
     
        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.
     
     
     5.4 Byte Order
     
        As described in "APPENDIX B:  Data Transmission Order" of
        RFC791[2], 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.
     
     
     5.5 Trailer Format
     
        Trailer encapsulation is NOT specified for IEEE 802.17
        networks.
     
     
     5.6 Ringlet and Direction 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.
     
        Ringlet and Direction selection are left to the MAC.  The
        advanced version of this specification may change this.
     
     
     5.7 Higher Layer TTL and Ring TTL
     
        There is no correlation or interaction between the Higher Layer
        TTL and the IEEE 802.17 TTL.
     
     
     
     
     
     
     
     Kastenholz       Standards Track - Expires June 2003             7
     
     
                         IP Over Resilient Packet Rings   December 2002
     
     6  IPv4 Specific Details
     
     
     6.1 Address Resolution
     
        ARP[3] 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 [4]
     
          Editor's Notes
               The hardware type is to be allocated by IANA prior to
               publication
     
               We could overload the Ethernet 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 inany
               danger of running out of ARP hardware codes, we'll get
               an 802.17-specific one.
     
     
     7  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.
     
     
     7.1 Stateless Autoconfiguration
     
        IPv6 stateless autoconfiguration follows the rules and
        procedures in section 4 of RFC2464[5].
     
     
     7.2 Link Local Address
     
        IPv6 link-local addresses follow the rules and procedures in
        section 5 of RFC2464[5].
     
     
     7.3 Unicast Address Mappings
     
        IPv6 unicast address mappings follow the rules and procedures
        in section 6 of RFC2464[5].
     
     
     
     Kastenholz       Standards Track - Expires June 2003             8
     
     
                         IP Over Resilient Packet Rings   December 2002
     
     7.4 Multicast Address Mappings
     
        IPv6 multicast address mappings follow the rules and procedures
        in section 7 of RFC2464[5].
     
     
     8  MPLS Specific Details
     
        Transport of MPLS packets over IEEE 802.17 follows RFC3032[6].
        As with IPv6, the intent is to allow the IEEE 802.17 network to
        be treated as a simple Ethernet LAN.
     
     
     9  Security Considerations
     
        This specification provides no security measures.
     
        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, eg,
           flooding the IEEE 802.17 network with ARP broadcasts.  These
           attacks are limited to other class-C (best efforts) traffic.
        4. Attacks against the IEEE 802.17 ring management protocols
           are possible by stations that are directly connected to the
           ring.
        We note that all of these vulnerabilities exist today for
        transport of IP and MPLS over Ethernet networks.
     
     
     10 IANA Considerations
     
        There are no IANA considerations.  This specification does not
        define any number or name spaces that need to be centrally
        managed.
     
     
     11 References
     
        [1] Bradner, S., "Key words for use in RFCs to Indicate
            Requirements Levels", BCP 14 RFC 2119, March 1997
     
        [2] Postel, J., "Internet Protocol", RFC-791, USC/Information
            Sciences Institute, September 1981.
     
        [3] Plummer, D.C., "An Ethernet Address Resolution Protocol",
            RFC826, November 1982.
     
     
     Kastenholz       Standards Track - Expires June 2003             9
     
     
                         IP Over Resilient Packet Rings   December 2002
     
        [4] IANA, "Address Resolution Protocol Parameters,
            http://www.iana.org/assignments/arp-parameters 5 February
            2002.
     
        [5] Crawford, M., "Transmission of IPv6 Packets over Ethernet
            Networks", RFC2464, December 1998.
     
        [6] Rosen, E., et al, "MPLS Label Stack Encoding", RFC 3032,
            January 2001.
     
        [7] IEEE Draft P802.17 ôResilient Packet Ring Access Method and
            Physical Layer Specifications û medium access control
            parameters, physical layer interface, and management
            parametersö. Draft D1.1, October 25, 2002.
     
        Acknowledgments
     
        The author acknowledges and appreciates the work and comments
        of the IPoRPR working group and the IEEE 802.17 working group.
        In particular, the review and comments by Albert Herrera, John
        Lemon, Peter Jones, Leon Bruckman, and Vinay Bannai have been
        greatly appreciated.
     
     
     12 Author's Addresses
     
        Frank Kastenholz
        Juniper Networks
        10 Technology Park
        Westford, MA, 01886, USA
     
        Phone: +1 978 589 0286
        Email: fkastenholz@juniper.net
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Kastenholz       Standards Track - Expires June 2003            10
     
     
                         IP Over Resilient Packet Rings   December 2002
     
     
     
     Full Copyright Statement
     
        "Copyright (C) The Internet Society 2002. All Rights Reserved.
     
        This document and translations of it may be copied and
        furnished to others, and derivative works that comment on or
        otherwise explain it or assist in its implmentation may be
        prepared, copied, published and distributed, in whole or in
        part, without restriction of any kind, provided that the above
        copyright notice and this paragraph are included on all such
        copies and derivative works.  However, this document itself may
        not be modified in any way, such as by removing the copyright
        notice or references to the Internet Society or other Internet
        organizations, except as needed for the  purpose of developing
        Internet standards in which case the procedures for copyrights
        defined in the Internet Standards process must be followed, or
        as required to translate it into languages other than English.
     
        The limited permissions granted above are perpetual and will
        not be revoked by the Internet Society or its successors or
        assigns.
     
        This document and the information contained herein is provided
        on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
        ENGINEERING TASK FORCE DISCLAIMS 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."
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Kastenholz       Standards Track - Expires June 2003            11
     

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