Subject: RE: [IPORPR] draft of a core protocol spec

From: Leon Bruckman <[email-masked]>
Date: Thu, 7 Nov 2002 13:56:54 +0200

Frank,
My comments below.

Leon Bruckman

-----Original Message-----
From: Frank Kastenholz [mailto:[email-masked]]
Sent: Tuesday, November 05, 2002 5:03 PM
To: [email-masked]
Subject: [IPORPR] draft of a core protocol spec

     3  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 
        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 nodes 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.  
lb] Wrapping is optional, steering is normative.

When the 
        fault clears, the ring "unwraps" and/or the effected source 
        nodes "re-steer" their traffic.
lb] In steer protection the client in a node may select not to steer back,
thus avoiding a second hit. I would recommend to remove this sentence 

        The two rings are called the Inner ring and Outer ring.
lb] They are called ringlet0 (former outer) and ringlet1 (former Inner) 

        A node may transmit a packet in either direction around the 
        ring.  IEEE 802.17 includes MAC-level protocols to determine 
        the shortest path to each destination.
lb] My suggestion: "IEEE 802.17 includes MAC-level protocols to determine
the ring topology."

  Normally, the 802.17 
        MAC layer will automatically send packets via the shortest 
        path.  Alternatively, higher layers (such as IP) may explicitly 
        specify the ring to use. 

        All nodes 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 and 
        Gigabit Ethernet are currently specified; others may be 
        specified in the future.  The higher layers are shielded from 
        any media dependencies.
lb] SONET/SDH and 1 and 10 Gigabit Ethernet are specified in the draft 

        There are fairness and bandwidth-management elements.  There 
        are high, medium, and low priority services.  
lb] My suggestion: "There are 3 service classes: Class A that provides low
delay and delay variation, class B that includes a committed and a excess
component, and class C a best effort class.

Use of these 
        features by IP and MPLS is beyond the scope of this 
        specification.  Their use will be specified in a later 
        document.
lb] We could at least define the mapping of DiffServe to the RPR service
classes 

     Kastenholz        Standards Track - Expires May 2002             3 
                         IP Over Resilient Packet Rings   November 2002 
      
lb] RPR also defines a echo frame to verify connectivity between any two
stations on the ring at the RPR layer, and a flush frame that can be used to
avoid misorder when steering flows

        The IEEE 802.17 packet is similar to an Ethernet packet.  Its 
        format is: 

                             +--------------------+ 
                             | IEEE 802.17 Header | 
                             |      (16 bits)     | 
                             +--------------------+ 
                             | Destination MAC    | 
                             |  Address (48 bits) | 
                             +--------------------+ 
                             | Source MAC Address | 
                             |  (48 bits)         | 
                             +--------------------+ 
                             | Protocol Type      | 
                             |  Field (16 bits)   | 
                             +--------------------+ 
                             | Header Checksum    | 
                             |  (16 bits)         | 
                             +--------------------+ 
                             |       Payload      | 
                             |                    | 
                             +--------------------+ 
                             |         FCS        | 
                             +--------------------+ 

        Where 

        IEEE 802.17 Header 
            Is a 16-bit IEEE 802.17 header. 

            The format of the RPR header is: 

                 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
                 |          TTL          |RI|FE|  PT |  SC |WE|E | 
                 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
lb] The last bit should be R and not E

            Where 

            TTL 
                Is the Time To Live for the packet.  It is decremented 
                by each station on the IEEE 802.17 ring.  If the TTL 
                reaches 0 it is removed from the ring.  This field is 
                set by the interface hardware. 

                NOTE WELL that this TTL is not related in any way to 
                the TTL in IPv4 and MPLS headers nor the hop-count in 
                IPv6 headers. 

            RI  Ring Identifier 
                Which the ring on which the packet was originally 
                transmitted. 
lb] Indicates the ringlet onto which....

     Kastenholz        Standards Track - Expires May 2002             4 
                         IP Over Resilient Packet Rings   November 2002 

            FE  Fairness Eligible 
                Indicates whether the packet is subject to the IEEE 
                802.17 fairness algorithm or not. 

            PT  Packet Type 
                Is a type field used to discriminate various IEEE 
                802.17 management and control packets from data 
                packets. 
lb] The name has been changed to FT: frame type

            SC  Service Class 

            WE  Is the Wrap Eligible bit. It indicates whether the 
                packet may be wrapped when the ring is wrapped.  

            R   Is reserved. 

        Destination MAC Address 
            Is the 48-bit MAC address of the destination node.  This 
            may be a multicast or broadcast address.  This address is 
            an IEEE 802 address. 

        Source MAC Address 
            Is the 48-bit MAC address of the source node.  This may be 
            a multicast or broadcast address.  This address is an IEEE 
            802 address.
lb] I suppose you have a "cut and paste" error: SA can never be anything but
a unicast address.

        Protocol Type 
            This is the 16-bit type field.  It identifies the protocol 
            of the payload 

        Header Checksum 
            Is a HEC-16 over the 802.17 header, Source and Destination 
            MAC addresses, and Protocol Type. 

        Payload 
            Is the IEEE 802.17 packet's payload.  This is the IP or 
            MPLS packet. 

        FCS 
            Is a CRC-32 over the entire IEEE 802.17 packet. 
lb] Excluding the header

     4  General 

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

     Kastenholz        Standards Track - Expires May 2002             5 
                         IP Over Resilient Packet Rings   November 2002 

     4.1 IEEE 802.17 Header 

        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 [8].  This section specifies how those 
        parameters are to be used: 

         TTL In the absence of any recommended value in IEEE 802.17, 
             the TTL SHOULD be set to 255. 
lb] There is no need (nor a standard way) to indicate TTL to the MAC. The
MAC can calculate it based on the DA

         RING 
             The ringlet on which a packet is transmitted SHOULD be 
             selected by the IEEE 802.17 MAC layer's Ringlet Selection 
             Process.  The higher layers SHOULD NOT select the ringlet. 

         FE  Fairness Eligible 
             No value should be specified for Fairness Eligible.  The 
             default treatment, specified in [8] is used.. 

         PT  Packet Type 
             The packet type is "data packet". 
lb] FT

         SC  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".  Use of different service classes is left for a 
             later specification. 
lb] We should at least specify the default mapping of DSCP into classes

_______________________________________________
IPORPR mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iporpr

---

From: "albherre" <[email-masked]>
Date: Thu, 7 Nov 2002 09:59:26 -0500

Leon,

Just a suggestion after a quick read.

> lb] We should at least specify the default mapping of DSCP into classes

ah] I would suggest we leave Diffserv mappings out of the 
core spec and address these when we re-charter for future work
as per the current charter.

Albert

---

From: Helen Butcher <[email-masked]>
Date: Thu, 07 Nov 2002 10:54:06 -0500

>as per the current charter.

As a service provider company, we have interest to see how DiffServe
will be supported by RPR. If it is put off to a future time, it would be 
helpful
to indicate when it will be addressed.

Thanks,
Helen.

---

From: "albherre" <[email-masked]>
Date: Thu, 7 Nov 2002 11:27:25 -0500

On the current charter, we've set a re-charter
milestone of March 2003 to address extended features.
This does not stop the WG from discussing the
issues now. It's actually best to start thinking about
these extended features now to avoid long
delays/discussions when the time comes.

Albert

----- Original Message -----
From: "Helen Butcher" <[email-masked]>
To: "albherre" <[email-masked]>; "Leon Bruckman" <[email-masked]>;
"'Frank Kastenholz'" <[email-masked]>; <[email-masked]>
Sent: Thursday, November 07, 2002 10:54 AM
Subject: Re: [IPORPR] draft of a core protocol spec

---

From: Helen Butcher <[email-masked]>
Date: Thu, 07 Nov 2002 11:46:12 -0500

OK. We'll work with our vendors and will look forward to seeing
mailing list discussions.

Thanks,
Helen.