Subject: Re: Support for multicast in the ForCES protocol

From: "Putzolu, David" <[email-masked]>
Date: Mon, 24 Nov 2003 16:53:10 -0800

[chair hat off]
Jamal Hadi Salim wrote >
David Putzolu wrote > >
> Ok, thanks for providing this because it cleared some confusion as to
> what angle you are looking at things.
> We are being bitten by lack of some NPF document again (i saw your
> description before in my brief glance of an NPF doc at MPLS). As i
> mentioned the need for NPF documents is to at least understand what
one
> is arguing against. We would have saved a lot of bandwith on this
> thread.

I used XML because it is a well known and fairly understandable 
way of expressing structured information.  I didn't base the
example on any NPF materials.  Likely this is a case of some
NPF proposal using XML and my example using XML both for the 
same reasons: it is useful :)

> > In the multicast case, I assume each FE would have a different set
> > of IDs for the LFBs (perhaps the IPv4 FIB LFB would be #17 on
> > FE#1, but would be #12 on FE#2. So just multicasting the above
> > message would not make any sense.
> 
> Why would the LFBID change depending on whether it was unicast or
> multicast? The LFBID would stay pretty static across FEs,
> and is probably issued by IANA.

I assume IANA will issue LFB *type* identifiers - so there would 
indeed be a single one for IPv4 FIB type.  I had also assumed that
individual FEs will instantiate LFBs of each type one or more 
times, with assigned instance identifiers.  For those familiar with
OO, this is equivalent to the difference between declaring classes 
and instantiating objects.

More concretely:
FE1 has two IPv4 FIBs (IANA FIB type ID = 37): FIB1 (instance ID=17) and

   FIB2 (instance ID=21).
FE2 has one IPv4 FIB (IANA FIB type ID = 37): FIB3 (instance ID=12) and 
   FIB4 (instance ID=23).
The goal is to add an entry to FIB1 and FIB4, but not FIB2 or 
FIB3,  and to use multicast to do it.

Using netlink2 terminology, I'd be worried about 
multicasting a RTM_NEWROUTE command to both FEs, because
it would affect all 4 FIBs.  Adding the PID attribute and having
it map to instance identifiers to the mcast message doesn't seem 
to help,  because in a multicast message the identical PID value 
would be sent to both FE recipients.

One solution to allow type-based (as opposed to instance-based)
addressing is to stipulate that multicast can only be used when 
there is exactly one instance of each LFB type on every
FE.  This solves the problem, but it narrows the utility of 
multicast significantly.

> I am begining to understand where all the confusion was coming from.
> I have to say i found it strange when i saw mentions of 
> multicast groups per LFB that were posted earlier. Please make those 
> NPF documents available.

The most relevant NPF document (and the only one I've consulted 
while participating in this discussion) is the NPF IPv4 
forwarding API, which can be found at:
http://www.npforum.org/techinfo/IPv4_IA.pdf

However, my concern about IANA-defined LFB type identifiers
vs. runtime assigned LFB instance identifiers in the context
of multicast is independent of the NPF docs.

I'm probably missing something here - I'm not a netlink2 expert -
and there is probably a way to address the concern above 
while using multicast and still allowing multiple instances 
of each LFB type per FE, without requiring an explosion
of multicast groups.  However, I couldn't find it in my readings
or recollection, so please help me out here by pointing it out!

Cheers,
David

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 24 Nov 2003 22:31:39 -0500

> same reasons: it is useful :)

I'll take your word for it.

> I assume IANA will issue LFB *type* identifiers - so there would

Thats what i thought you meant.

> it would affect all 4 FIBs.

You must have missed the table Id then.
Look at section 8.4.2.1 "IPv4 and IPv6 Forwarding LFB Template"

> Adding the PID attribute and having

Refer to above and see if it makes sense to you.

> FE.  This solves the problem, but it narrows the utility of

I think you missed some details refer to above and post again.

> http://www.npforum.org/techinfo/IPv4_IA.pdf

Thanks - I will look at this; definetely not the same set of docs i was
refering to.

> of multicast is independent of the NPF docs.

Its hard to tell when you are still hiding documents ;->

> or recollection, so please help me out here by pointing it out!

I am responding because i think you are sincere in trying to understand
this. I am hoping you will at least refer to the sections of the
netlink2 draft i am refering to.

I think you are mixing two things:
1) Netlink2 PIDs which can be mapped to entities that can be addressed;
these could be FEs, CEs, LFB proxies, LFBs each of which could
be a unicast, logical, broadcast or multicast
2) the type field; this is of the format LFB_CMD - example
RTM_NEWROUTE which translates that the netlink2 message is
directed at an IPV4/6 fwding LFB and it is an add operation.

Assume for simplicity, all FEs and a single CE are on the same
multicast group (say UDP address 224.x.y.z/port 4312).

now lets look at your example:

-----------------------
FE1 has two IPv4 FIBs
(IANA FIB type ID = 37): FIB1 (instance ID=17) and
FIB2 (instance ID=21).

-----------------------

There are more than one way to skin this cat.
IANA FIB type ID = 37 is mapped into the RTM_*
Essentially theres a decimal 37 and a 0(define for NEWROUTE) in the
bitmap that represents the type field.
[1 represents DELROUTE and 2 GETROUTE]
- to add a route, use RTM_NEWROUTE
* several ways to skin this cat in terms of PID:
You can direct it at the all FEs PID, a all-RTM-LFBS pid etc

Now that you have define your target above, you need to
target something within the RTM LFB. This is where section
8.4.2.1 "IPv4 and IPv6 Forwarding LFB Template" comes in.

- call FIB1 table ID 1
- call FIB2 table ID 2

You can send a single message to add both or two separate message
one targeting FIB 1 and another targeting FIB 2.

Refer to section 7.5.4 "Batching"

Case1: Single message
---------------------

You put two templates as in 8.4.2.1 one for each FIB into the single
netlink2 message as defined in section 7.5.4 of the form:

   NLMSGHDR:OET:STFIB1:STFIB2

where STFIB1 is the service template for FIB1 and the other for FIB2.

Case2: two messages
-------------------

NLMSGHDR:OET:STFB1 followed by
NLMSGHDR:OET:STFIB2.
You could put both messages in the same Netlink2 PDU as described in
section 7.5.4.

So far so good?

Observe that the transport used is multicast requires that we send a single
message to a single socket.
The above addressing doesnt have to change if you used TCP unireplicate to
FE1 and another to FE2. You just send the same copy to the two FEs
on two different unicast sockets. The effort is just a little more ;->

I just wanted to clarify how this is done. I am sure you have other
questions.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 24 Nov 2003 22:38:43 -0500

> one targeting FIB 1 and another targeting FIB 2.

-> Sorry, i think you meant address FIB4 instead of FIB2;
s/FIB 2/FIB 4/g

The example still holds.

cheers,
jamal