Subject: [Ipoverib] capability flags

From: Vivek Kashyap <[email-masked]>
Date: Fri, 9 Nov 2001 01:17:34 -0800 (PST)

> >
> >2. IB Transport Service
> >Option a: Require support of unreliable datagram; permit use of others
> >Option 1: Title RFC something like “Encapsulation of IP in IB Unreliable
> >Datagram”, require use of unreliable datagram, and within this RFC
> >remain silent with respect to other transport methods (neither implies
> >nor prohibits use of other IB transports).
> 
> Option 1 with one important addition - a mechanism for an IPoIB node to
> determine upfront what (if any) non-default transport is supported on a
> remote node.

I am in full agreement here. IP support over UD is mandatory but an IP
stack may choose to support IP over other transport modes on a
particular interface. This information is exchanged between the peers
through the use of capability flags.

> >6c. Contents of the hardware address for IBARP (in addition to QPN,
> >GUID, and QKey)
> >Option a: Include Capability Flags
> >Option 1: Do not include Capability Flags (but possibly include a
> >reserved field that could be used for capability flags in the future as
> >RFCs are developed to define the capabilities)
> 
> I'd like to propose Option 2: 
> Do not embed any capability flags in IBARP. The capability is a per-node
> property. It's quite a waste to include that in every ARP handshake.
> Instead, embed the capability flags somewhere else in the SA database
> (e.g. the CapabilityMask of PortInfo) for which any node on the subnet can
> query.
> 

The flags let the remote peer know whether IP is supported over other
transports. Further one may choose to support IP over only some of the
IB transport modes per interface. Thus it is not an IB construct but
an IP construct that is being exchanged. This is not a per-node
property but a per IP interface property and the property of the IP
address(es) associated with the IP interface. The same is true about
the QPN flag.

There were three sets of IB hardware addresses proposed to be included
in the ARP packet by me, Jerry and Joe et. al in our respective IDs.
They are (roughly):

Vivek: LID  + Capability flags (8) + QPN + Q_Key + GUID

Jerry: reserved (8) + QPN + GUID

Joe: type + length + reserved (16) + GUID + reserved (8) + QPN + Q_Key + GID 

So, really all of us have proposed enough space to include the flags.
There is no extra effort in sending and receiving flag bits compared
to pad/reserve bits. With the provision that in the default case these
bits are transmitted as zero and ignored on receive there is full
assurance that all implementations will interoperate. Any
implementation not implementing IP over other modes (non-UD) will set
the bits to 0 and will ignore the entries in the field in received
packets. An implementation supporting this feature on receiving 0
flags will know that the peer doesn't support IP over non-UD
transport. 

Vivek

-- 
Vivek Kashyap
IBM
[email-masked] 
[email-masked] 
503 578 3422 (o)
-- 
Vivek Kashyap
IBM
[email-masked] 
[email-masked] 
503 578 3422 (o)

_______________________________________________
IPoverIB mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ipoverib