Subject: [Policy] Re: IP Protocol value range

From: "Mircea Pana"<[email-masked]>
Date: Fri, 01 Feb 2002 12:09:07 -0500

Here they are. I've just listed them all (including the ones that were
already specified). I'm not sure what would be a formal notation for the
number of bits that a PolicyBitStringValue must have. E.g. An IPToS
variable can be matched against BitString values with *exactly* 8 bits.

See also the note on SNAP at the bottom.

Regards,
Mircea.

PolicySourceIPv4Variable........PolicyIPv4AddrValue

PolicySourceIPv6Variable........PolicyIPv6AddrValue

PolicyDestinationIPv4Variable...PolicyIPv4AddrValue

PolicyDestinationIPv6Variable...PolicyIPv6AddrValue

PolicySourcePortVariable........PolicyIntegerValue (0..65535)

PolicyDestinationPortVariable...PolicyIntegerValue (0..65535)

PolicyIPProtocolVariable........PolicyIntegerValue (0..255)

PolicyIPVersionVariable.........PolicyIntegerValue (0..15)

PolicyIPToSVariable.............PolicyIntegerValue (0..255)
                                PolicyBitStringValue (8 bit)

PolicyDSCPVariable..............PolicyIntegerValue (0..63)
                                PolicyBitStringValue (6 bit)

PolicyFlowIdVariable............PolicyIntegerValue (0..1048575)
                                PolicyBitStringValue (20 bit)

PolicySourceMACVariable.........PolicyMACAddrValue

PolicyDestinationMACVariable....PolicyMACAddrValue

PolicyVLANVariable..............PolicyIntegerValue (0..4095)
                                PolicyBitStringValue (12 bit)

PolicyCoSVariable...............PolicyIntegerValue (0..7)
                                PolicyBitStringValue (3 bit)

PolicyEthertypeVariable.........PolicyIntegerValue (0..65535)
                                PolicyBitStringValue (16 bit)

PolicySourceSAPVariable.........PolicyIntegerValue (0..255)
                                PolicyBitStringValue (8 bit)

PolicyDestinationSAPVariable....PolicyIntegerValue (0..255)
                                PolicyBitStringValue (8 bit)

PolicySNAPVariable..............PolicyIntegerValue (0..65535)
                                PolicyBitStringValue (16 bit)

PolicyFlowDirectionVariable.....PolicyStringValue (IN, OUT)

Note:

SNAP actually stands for "IEEE 802.1a SubNetwork Attachment Point". See
http://www.ietf.org/rfc/rfc1483.txt "4.1.  LLC Encapsulation for Routed
Protocols" for example. The SNAP header includes two fields: OUI (3
octets) and PID (2 octets).

I have two comments here:
1. IMO, PCIMe incorrectly describes SNAP as "Sub-Network Access
Protocol".
2. Was it intended for the PCIMe class "PolicySNAPVariable" to represent
only the PID part of the SNAP header (2 octets)? Or should it reflect
the entire header: OUI+PID (5 octets).

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

---

From: "Ron Cohen" <[email-masked]>
Date: Wed, 6 Feb 2002 12:37:29 +0200

I agree. I think that we should add an OID variable as well. I think
that this would answer the remarks by Mircea as well as the
input/solution proposed by Andrew. I'm assuming that we don't need to
support the 40 bit OIU (see Andrew's email).

How about the following definition:

NAME PolicySNAPOIDVariable
DESCRIPTION The OID value of the Sub-Network Access Protocol (SNAP)
field for 802.2 SNAP encapsulation. 
The value 00-00-00 indicates the standard SNAP encapsulation (RFC 1042).
OID value 00-00-F8 indicates the bridged ethertype (IEEE
802.1H)

ALLOWED VALUE TYPES:
 - PolicyBitStringValue (24 bit)

DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE 
PROPERTIES (none)

Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Joel M. Halpern
> Sent: Tuesday, February 05, 2002 10:52 PM
> To: Robert Moore; Ron Cohen
> Cc: [email-masked]; 'Mircea Pana'; 'IETF Policy'; 
> [email-masked]
> Subject: RE: [Policy] Re: IP Protocol value range
> 
> 
> If we are going to do that, we should add a PolicySNAPOIDVariable as 
> well.  If you are looking at SNAP/SAP encapsulated 
> information, you must 
> check the OID for 0 before you can treat the last two bytes 
> as an etherType.
> Yours,
> Joel M. Halpern
> 
> At 12:56 PM 2/5/02 -0500, Robert Moore wrote:
> >Let me propose an update to the PCIMe text. If this isn't 
> exactly right,
> >it should at least be specific enough for people to comment on.
> >It's a complete replacement for section 5.12.19:
> >NAMEPolicySNAPTypeVariable DESCRIPTIONThe value of the 
> Sub-Network Access 
> >Protocol                     (SNAP) Type field for 802.2 
> SNAP encapsulation.
> >
> >ALLOWED VALUE TYPES:  - PolicyIntegerValue (0..65535)  - 
> >DERIVED FROMPolicyImplicitVariable ABSTRACTFALSE  PROPERTIES(none)
> >
> >
> >Regards,
> >Bob
> >
> >Bob Moore
> >Advanced Design and Technology
> >Application Integration Middleware Division
> >IBM Software Group
> >+1-919-254-4436
> >[email-masked]
> >
> >d821c.jpg"Ron Cohen" <[email-masked]>
> >
> >
> >d8356.jpg
> >d836d.jpg
> >"Ron Cohen" <[email-masked]>
> >
> >02/05/02 06:54 AM
> >
> >d8380.jpg
> >
> >To:"'Mircea Pana'" <[email-masked]>, Robert 
> Moore/Raleigh/IBM@IBMUS
> >cc:<[email-masked]>, "'IETF Policy'" <[email-masked]>, 
> ><[email-masked]>
> >Subject:RE: [Policy] Re: IP Protocol value range
> >
> >
> >Mircea, Bob
> >
> >
> >PCIMe defines:
> >
> >PolicySNAPVariable: The protocol number over a Sub-Network Access
> >Protocol (SNAP) SAP encapsulation.
> >
> >Explanation:
> >
> >IEEE 802.2 defines two encapsulations, following the Ethernet length
> >field:
> >
> >- One with 3 bytes, SSAP, DSAP and CNTRL. The first two are 
> represented
> >by the PolicySourceSAPVariable and PolicyDestinationSAPVariable.
> >- The second called the 802.2 SNAP encapsulation, and adds 5 bytes,
> >where the last two bytes are called the SNAP type. This is the
> >equivalent of the Ethernet Type. The intention was that the
> >PolicySNAPVariable would represent this two byte SNAP type field.
> >
> >I suggest that we rename this variable to PolicySNAPTypeVriable and
> >remove the current ambiguity.
> >
> >
> >Ron
> >
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of Mircea Pana
> > > Sent: Monday, February 04, 2002 5:36 PM
> > > To: Robert Moore
> > > Cc: [email-masked]; IETF Policy; [email-masked]
> > > Subject: Re: [Policy] Re: IP Protocol value range
> > >
> > >
> > > ...and just to add to my confusion, RFC1042 defines the 
> *same* SNAP
> > > header as
> > > "an extension of the LLC header called the Sub-Network 
> Access Protocol
> > > (SNAP)" :-0
> > >
> > > So, a reference to the actual definitions (RFC, IEEE 
> etc.) may help if
> > > added in PCIMe. IMO, it is less important what exactly 
> this (or other)
> > > PolicyVariable represents, more important is to define it
> > > unambiguously.
> > >
> > > Regards,
> > > Mircea.
> > >
> > >
> > > Robert Moore wrote:
> > > >
> > > > >SNAP actually stands for "IEEE 802.1a SubNetwork 
> Attachment Point".
> > > > See
> > > > To be honest, I don't know what we meant to refer to with
> > > > PolicySNAPVariable. (I think this class came from Cisco - in
> > > > any case, I know it didn't come from IBM.) Some possibilities:
> > > >
> > > > Currently in PCIMe: Sub-Network Access Protocol.
> > > >
> > > > Mircea's suggestion: IEEE 802.1a SubNetwork Attachment Point.
> > > >
> > > > On acronymfinder.com: Subnetwork Access Protocol,
> > > > Standard Network Access Protocol (in bold, for some
> > > > reason), Small Network Access Package, and a bunch
> > > > of other options that are plainly not what we're
> > > > talking about.
> > > >
> > > > Maybe Andrea, or Yoram, or Yoram, or Ron, or John can tell
> > > > us what we meant when we defined PolicySNAPVariable.
> > > > And maybe they'll even agree! :-)
> > > >
> > > > Regards,
> > > > Bob
> > > >
> > > > Bob Moore
> > > > Advanced Design and Technology
> > > > Application Integration Middleware Division
> > > > IBM Software Group
> > > > +1-919-254-4436
> > > > [email-masked]
> > >
> <https://www1.ietf.org/mailman/listinfo/policy>https://www1.ie
tf.org/mailm 
> an/listinfo/policy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 06 Feb 2002 08:00:59 -0500

[Retransmission, this time saying the right thing...]

If we are going to do that, we should add a PolicySNAPOIUIVariable as 
well.  If you are looking at SNAP/SAP encapsulated information, you must 
check the OUI for 0 before you can treat the last two bytes as an etherType.
Yours,
Joel M. Halpern

[I wrote OID for some reason last time.  I meant OUI.]

At 12:56 PM 2/5/02 -0500, Robert Moore wrote:
>Let me propose an update to the PCIMe text. If this isn't exactly right,
>NAMEPolicySNAPTypeVariable DESCRIPTIONThe value of the Sub-Network Access 
>Protocol                    (SNAP) Type field for 802.2 SNAP encapsulation.
>
>200e7d0.jpg"Ron Cohen" <[email-masked]>
>
>
>200e7e6.jpg
>200e7f8.jpg
>200e80c.jpg
>To:"'Mircea Pana'" <[email-masked]>, Robert Moore/Raleigh/IBM@IBMUS
>- One with 3 bytes, SSAP, DSAP and CNTRL. The first two are represented
> > ...and just to add to my confusion, RFC1042 defines the *same* SNAP
> > header as
> > "an extension of the LLC header called the Sub-Network Access Protocol
> > (SNAP)" :-0
> >
> > So, a reference to the actual definitions (RFC, IEEE etc.) may help if
> > added in PCIMe. IMO, it is less important what exactly this (or other)
> <https://www1.ietf.org/mailman/listinfo/policy>https://www1.ietf.org/mailm 
> an/listinfo/policy
> >
>

---

From: "Ron Cohen" <[email-masked]>
Date: Thu, 7 Feb 2002 18:07:17 +0200

Its OUI - my mistake
 
Ron

-----Original Message-----
From: Robert Moore [mailto:[email-masked]] 
Sent: Thursday, February 07, 2002 5:28 PM
To: Ron Cohen
Cc: [email-masked]; 'Joel M. Halpern'; 'Mircea Pana'; 'IETF Policy';
[email-masked]

Somehow I seem to be the only person here without a copy of the relevant
802.2 spec. So I have no way of deciding between Ron's OID proposal and
Joel's OUI one. I agree with Mircea that the most important thing here
is to state, very clearly and unambiguously, the contents of each of our
variable classes. I'm just not in a position to do that myself.

Regards,
Bob

Bob Moore

	

	02/06/02 05:37 AM

To: "'Joel M. Halpern'" <[email-masked]>, Robert
Moore/Raleigh/IBM@IBMUS
cc: <[email-masked]>, "'Mircea Pana'" <[email-masked]>,
"'IETF Policy'" <[email-masked]>, <[email-masked]>
Subject: RE: [Policy] Re: IP Protocol value range

ALLOWED VALUE TYPES:

Ron

tf.org/mailm

---

From: "Ron Cohen" <[email-masked]>
Date: Sat, 9 Feb 2002 19:11:20 +0200

Andrew,

I like your definitions. I didn't mean to restrict the OUI values, but
rather to provide examples. 

Ron

> Behalf Of Andrew Smith
> Sent: Thursday, February 07, 2002 8:09 PM
> To: Robert Moore
> Cc: 'IETF Policy'
> Bob,
> How about this for the Type variable:
> 
> "NAME PolicySNAPTypeVariable
> DESCRIPTION The value of the 4th and 5th octets of the 
> Sub-Network Access
> Protocol (SNAP) Protocol Identifier field for IEEE 802 SNAP 
> encapsulation
> when the PolicySNAPOUIVariable
> indicates one of the two Encapsulated Ethernet frame formats. 
> This value is
> undefined for other values of PolicySNAPOUIVariable.
> 
> ALLOWED VALUE TYPES: - PolicyIntegerValue (0..65535)
> 
> PROPERTIES (none)"
> Does this "language" have REFERENCE clauses? That would be a 
> good place to
> put the appropriate RFCs and IEEE documents.
> 
> I'm still a bit unclear on Ron's proposal: if we don't allow 
> the OUI to be
> other than 00-00-00 or 00-00-F8 then shouldn't there be some type of
> enumerated list of these "allowed values"? Or is this 
> language not that
> formal? Otherwise we have to add something like "Other values 
> of OUI are not
> supported".
> 
> And one other wrinkle is that people who live in what is 
> often known as
> "IBM-endian" land might interprete 00-00-F8 in a different 
> way to those
> hailing from "Ethernet-land" (I can't remember which is 
> "Big-" and which is
> "Little-" endian - people tend to call them "Ethernet order" 
> and "Token-Ring
> order"). The official IEEE chapter and verse on this is (from 
> the the book
> of "IEEE 802 Overview and Architecture"):
> 
> "3.8 Hexadecimal Representation: The representation of a 
> sequence of octet
> values in which the values of the individual octets are 
> displayed in order
> from left to right with each octet value represented as a two-digit
> hexadecimal numeral, and with the resulting pairs of 
> hexadecimal digits
> separated by hyphens. The order of the hexadecimal digits in 
> each pair, and
> the mapping between the hexadecimal digits and the bits of 
> the octet value,
> are derived by interpreting the bits of the octet value as a 
> binary numeral
> using the normal mathemat-ical rules for digit significance."
> 
> as opposed to
> 
> "3.2 bit-reversed representation: The representation of a 
> sequence of octet
> values in which the values of the individual octets are 
> displayed in order
> from left to right with each octet value represented as a two-digit
> hexadecimal numeral, and with the resulting pairs of 
> hexadecimal digits
> separated by colons. The order of the hexadecimal digits in 
> each pair, and
> the mapping between the hexadecimal digits and the bits of 
> the octet value,
> are derived by reversing the order of the bits in the octet value and
> interpreting the resulting bit sequence as a binary numeral 
> using the normal
> mathematical rules for digit significance.
> NOTE- The bit-reversed representation is applicable to LAN 
> MAC addresses for
> use in a Token Ring (IEEE 802.5) or FDDI environment. See 
> Figure 8 for a
> comparative example of Bit-reversed and Hexadecimal Representation.
> 
> In other words, 00-00-F8 is supposed to unequivocably mean 
> "Ethernet order"
> as opposed to 00:00:EF which means the same thing in 
> Token-Ring land. Not a
> lot of people know that. But if we write things like 00-00-F8 
> in the Policy
> document, we've got to reference this convention. So how 
> about the following
> revision of Ron's proposal for the OUI variable:
> 
> "NAME PolicySNAPOUIVariable
> DESCRIPTION The value of the first three octets of the 
> Sub-Network Access
> Protocol (SNAP)
> Protocol Identifier field for 802.2 SNAP encapsulation, containing an
> O.U.I..
> The value 00-00-00 indicates the encapsulation of Ethernet frames (RFC
> 1042).
> OID value 00-00-F8 indicates the special encapsulation of 
> Ethernet frames by
> certain types of bridge (IEEE 802.1H). Other values are not 
> supported. These
> O.U.I. values are to be interpreted according to the endian-notation
> conventions of IEEE 802. For either of these encapsulations, 
> the remainder
> of the Protocol Identified field is indicated by 
> PolicySNAPTypeVariable.
> 
> ALLOWED VALUE TYPES:
> - PolicyBitStringValue (24 bit) ***
> 
> PROPERTIES (none)"
> Note ***: is there such thing as a "PolicyOctetStringValue (3 
> octet)" type?
> Using BitString leads to additional interpretation problems 
> unless it is
> clearly defined somewhere else what endian order is implied.
> 
> I'd suggest that the OUI variable precede the Type one in the 
> document.
> That's my 2 cents - take this message as an I.O.U. :-)
> 
> Andrew
> 
> 
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Robert Moore
> Sent: Thursday, February 07, 2002 7:28 AM
> To: Ron Cohen
> Joel's OUI one. I agree with Mircea that the most important 
> thing here is to
> state, very clearly and unambiguously, the contents of each 
> of our variable
> classes. I'm just not in a position to do that myself.
> 
> Regards,
> Bob
> 
> Bob Moore
> cc: <[email-masked]>, "'Mircea Pana'" 
> <[email-masked]>, "'IETF
> Policy'" <[email-masked]>, <[email-masked]>
> > > > > >http://www.ietf.org/rfc/rfc1483.txt "4.1. LLC 
> Encapsulation for
> > > > > Routed
> > > > > >2. Was it intended for the PCIMe class 
> "PolicySNAPVariable" to
> > > > > represent

---

From: "Robert Moore" <[email-masked]>
Date: Mon, 11 Feb 2002 16:37:56 -0500

OK, taking Andrew's text as a starting point, I've created a new PCIMe
section for the OUI variable, and updated the section for the SNAP Type
variable.  Since Ron said that the two Ethernet values were just supposed
to be examples, I amended Andrew's text to say that other values *are*
allowed, rather than to say that they are not allowed.  Also, since the
answer to Andrew's question is "No, there isn't a PolicyOctetStringValue
class," I went ahead and did the subtyping for the new variable the same
way it was done for the others.  Finally, rather than opening up the
*enormous* issue of canonical versus non-canonical formats, I stopped with
Andrew's one sentence about endian-ness.

Anyway, here's the new text, available for your comments:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
5.12.19.    The Class "PolicySNAPOUIVariable"
     NAME PolicySNAPOUIVariable
     DESCRIPTION         The value of the first three octets of the Sub-
                         Network Access Protocol (SNAP) Protocol Identifier
                         field for 802.2 SNAP encapsulation, containing an
                         Organizationally Unique Identifier (OUI).  The
                         value 00-00-00 indicates the encapsulation of
                         Ethernet frames (RFC 1042).  OUI value 00-00-F8
                         indicates the special encapsulation of Ethernet
                         frames by certain types of bridges (IEEE 802.1H).
                         Other values are supported, but are not further
                         defined here.  These OUI. values are to be
                         interpreted according to the endian-notation
                         conventions of IEEE 802.  For either of the two
                         Ethernet encapsulations, the remainder of the
                         Protocol Identifier field is represented by the
                         PolicySNAPTypeVariable.

                         ALLOWED VALUE TYPES:
                         - PolicyIntegerValue (0..16777215)
                         - PolicyBitStringValue (24 bits)

5.12.20.    The Class "PolicySNAPTypeVariable"
     NAME                PolicySNAPTypeVariable
     DESCRIPTION         The value of the 4th and 5th octets of the Sub-
                         Network Access Protocol (SNAP) Protocol Identifier
                         field for IEEE 802 SNAP encapsulation when the
                         PolicySNAPOUIVariable indicates one of the two
                         Encapsulated Ethernet frame formats.  This value
                         is undefined for other values of
                         PolicySNAPOUIVariable.

                         ALLOWED VALUE TYPES:
                           - PolicyIntegerValue (0..65535)
                           - PolicyBitStringValue (16 bits)

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Regards,
Bob

Bob Moore

                      "Ron Cohen"                                                                          
                      <[email-masked]>         To:       "'Andrew Smith'" <[email-masked]>, Robert       
                      Sent by: policy-          Moore/Raleigh/IBM@IBMUS                                    
                      [email-masked]           cc:       "'IETF Policy'" <[email-masked]>                 
                                               Subject:  RE: [Policy] Re: IP Protocol value range          
                                                                                                           
                      02/09/02 12:11 PM                                                                    

Andrew,

Ron