[mpls] Thoughts on Ancillary Data Indicators.

[Loa Andersson <[e-mail]>]

Design Team,

We have discussed how to carry ancillary data in  in an MPLS packet and 
how to include indicators on the presences of such data in the label 
stack since the design team started. I think we have some convergence 
and that it is time to float an idea that could be the basis for a 
consensus. Please note that the actual consensus call will be made on 
the mpls wg mailing list, while this is for discussion preparing such a 
consensus call in the design team.

The proposals we have for indicators often rely on assignment of a base 
special purpose label. The number of such labels are limited.

I think we can agree on the following:

- We want to limit the number of new assignments of base special purpose
   labels as much as possible

- We have a standardized associated channel, the GAL/GACH. We are not
   going to change the associated channel. The associated will remain as
   specified in RFC 5586. The ACH is found immediately after the label
   carrying the Bottom of Stack (BoS) bit.

- We therefore need a (base) special purpose label to serve as the
   forwarding action indicator carrier.

- It is attractive to "re-purpose" the ELI to also fill the role as a
   general (generic?) forwarding action indicator. This may be done by
   using the TTL and TC fields of the ELI as flags indicating which
   service is requested.

   However, in order to do this it must be shown that there is no
   potential interference between the normal service supplied by the
   ELI/EL and the services indicated by the flags.

- If we can't demonstrate the non-interference then we should assign
   specific forwarding indicator action base special purpose label and
   leave the ELI/EL unchanged.

- The flag field of the re-purposed ELI of the the specially assigned
   forwarding action indicator label must be made extendable. These
   labels "only" have 11 bits (8 bit TTL and 3 bit TC fields) that can
   be used as flags. Already in the very preliminary discussions we have
   had so far are almost using all the 11 bits, making the it necessary
   to make the indicator extendable.

/Loa



-- 

Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Bronze Dragon Consulting             phone: [phone]