Subject: [Ipoverib] Encapsulation Issues

From: Joe Pelissier <[email-masked]>
Date: Mon, 08 Oct 2001 12:02:34 -0700

Greetings,
Below is an updated list of the open issues that need to be decided to
complete the encapsulation work.  It is based on the original list I
posted many weeks ago and has been updated based on feedback I have
received.  The order in which the options are listed has no intended
correspondence to the individual internet drafts.  Please feel free to
forward updates to the list and I will attempt to maintain a
consolidated version.

Best Regards,
Joe Pelissier
[email-masked]

1. Determination of service level
Option a: Use SL from all hosts multicast group
Option 1: Use SL from path record

1a. Determination of service level
Option a: Include a flag provided by the subnet administrator that
indicates the SL of the all hosts multicast group may be used for IP
unicast communication.
Option 1: Do not include such a flag.

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).

3a. Relationship between IP and IB subnets
Option a: An IP subnet is contained within a single IB subnet.
Option 1: An IP subnet spans all IB subnets interconnected with IB
routers.

3b. Mapping IPv6 scope bits to IB GID scope bits (the answer to this is
implied by the decision made in 3a).
Option a: Use local scope in IB GID for all IP packets
Option 1: Use global scope in IB GID for all IP packets

4a. Mapping of IPv4 multicast address to IB multicast GID
Option a: Define an algorithmic mapping
Option 1: Define a method to dynamically map as required

4b. Mapping of IPv6 multicast address to IB multicast GID
Option a: Define an algorithmic mapping
Option 1: Define a method to dynamically map as required

5. Mapping of multicast GID to multicast LID
Option a: Define a mapping
Option 1: It’s the IBTA’s problem, let them fix it

6a. Contents of the hardware address for IBARP (in addition to QPN,
GUID, and QKey)
Option a: Include LID
Option 1: Do not include LID

6b. Contents of the hardware address for IBARP (in addition to QPN,
GUID, and QKey)
Option a: Include GID
Option 1: Do not include GID

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)

7. Inclusion of GRH in IB subnet local unicast IP over IB packets (GRH
required in multicast packets and inter-IB subnet packets in accordance
with the InfiniBand specification)
Option a: Recommend inclusion of GRH in all IP over IB packets
Option 1: Remain silent (which leaves inclusion of GRH in unicast
packets optional as specified by the InfiniBand specification)

8. Inclusion of a field to identify the protocol (like an “Ethertype”).
Option a: Do not include a protocol identification field
Option 1: Do include an identification field

9.  Determination of multicast parameters for the multicast group used
for IBARP. (Note: there was a proposal to use the InfiniBand SIDR
mechanism; at this point there appears to be no one that believes this
is a workable solution).
Option a: Use a well-known MGID and do a MCGroup lookup to get the rest
of the parameters.
Option 1: Use a well-known ServiceName, do a ServiceRecord lookup to get
the MGID, and then do a MCGroup lookup for the rest of the parameters.

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

---

From: "H.K. Jerry Chu" <[email-masked]>
Date: Mon, 8 Oct 2001 12:42:54 -0700 (PDT)

Instead of diving right into protocol details, I'd like to suggest a
more structural approach for a design comparison. If we can agree upon
the design steps outlined in the following, we can better focus on
debating how each step should be fulfilled.

The following is a list of logical steps I believe are required for
a complete IPoIB protocol suite to specify.

1. Define the link boundary for an IPoIB link

When an IP stack is brought up on an IB/CA, the first thing a CA
must determine is what IPoIB link it belongs to. This step is required
in order to support a more flexible relationship between IP and IB
subnets. I.e. this step won't be needed if we simply use the local IB
link/subnet a CA is directly connected as the IP link. In that case it's
very similar to IP over Ethernet (w/o VLAN) - the link segment is the
one that an Ethernet NIC is directly connected to. But that approach
limits an IP subnet to have an identical boundary with an IB subnet.
That restriction has been deemed undesirable by many people.

A database must exist to provide the IPoIB link information for an IB
node to lookup during bootstrapping. Examples of this database includes
but not limited to MCGroupRecord, ServiceRecord.

Presumably the database is created through some administrative procedure.
Network administrators must first layout the IPoIB boundary for each IP
subnet, then program the database with the information.

2. Determine the per-link IB attributes

Now that we know how to draw the link boundary for IPoIB, we must decide,
among many different IB attributes, which should be considered as per-link
attributes. Candidates include, but not limited to MTU, P_Key, Q_Key,
SL, IB transport type. Note that per-link attributes and per-node
attributes described in 4 below must be mutually exclusive.

Once we reach a consensus on what per-link attributes should be, the
database from 1 above will be a natural place for keeping the values
of these attributes. An IB node will lookup for a local IPoIB link, and
use attributes values associated with the link to configure its IPoIB
stack during bootstrap.

3. Determine how to map IP multicast to IB multicast on each IPoIB link

There are a number of possibilities here, each has its pros and cons. I
proposed to define a fixed mapping from an IPv6 multicast address to an
IB MGID. The same can be done with IPv4 multicast address. Another
possibility is to use a dynamic mapping scheme. But that will incur a
lookup cost for each client when trying to translate an IP multicast
address.

Note that the mapping defined here must have a link-local scope wrt
IPoIB links. Otherwise multicast packets may leak out to other IB
nodes not belonging to the same IPoIB link. This requirement may impose
some restriction on how to draw IPoIB link boundary described in 1.

4. Determine the IPoIB link-layer address (or "hardware address" in
ARP's term) format

The IB attributes embedded in a link-layer address for IPoIB purpose
may include QPN, GUID, GID, LID, P_Key, Q_Key, SL, transport type...,
etc.

Once steps 1-3 have been accomplished, we should debate on the merit
of including each IB attribute, one by one.

I think the above steps will enable us to better focus on the details,
and hopefully to come to consensus on an IPoIB standard sooner. Please
comment.

Jerry