[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Closing the GELS Mailing List



Hi Neil,
 
I think there is a difference between a "data plane label" which is a Layer Information (LI) used by a given server layer and a "control plane label", which is a piece of information signaled between adjacent controllers for the purpose of connection provisioning. IMO the former is always a superset of the latter. Let's take, for instance, connection oriented Ethernet. MAC SA is a very important part of the data plane label because it identifies the source of the connection. However, the connection frames are forwarded according to MAC DA/VID, and hence connection ingress node, for example, needs only be signaled with this tuple by the downstream neighbor, hence the control plane label is MAC DA/VID (or just VID, for those who like the idea of the VID cross-connects architecture).
 
So, IMO IEEE should be responsible for the definition of data plane labels, while CCAMP for control plane labels.
 
Cheers,
Igor


neil.2.harrison@bt.com wrote:
Dimitri wrote 07 September 2007 16:36 in response to Adrian

> >
> > This is also something we would expect to describe within
> > CCAMP although
> > "what is a label" would come to us from the data plane
> specification.
>
> do i interpreet correctly your statement that if the
> specification that CCAMP is going to receive from IEEE does
> not speak about "label" and its encoding there will be no
> place to discuss any "label processing" and "label
> distribution" protocol in IETF - being domain-wide or link-local
> -
>
> in that case, isn't the .1Q specification outside scope of
> this effort since not referring - as of today at least - to
> any "label" semantic as part of the Ethernet frame header
> information field ?
>
> thanks,
> -d.

What do you think a MAC DA, MAC SA and VID are? These are all 'labels'.

You also have to remember that the nature of the labels required in a
traffic unit are determined by the type of the network mode one is
dealing with.

In the co-cs and co-ps modes we have a construction known as a
'connection'. This implies specific architectural requirements....but
the most significant, for this discussion at least, is that a connection
must have a single source. What this means is that one does not have to
incorporate a SA label in a co mode traffic unit....under defect-free
conditions it is redundant information as the connection itself provides
the source information. {Compare this to the cl-ps mode which does not
have connections...here having a SA in the traffic unit is essential}

Ergo why co-cs and co-ps mode technologies to date that respect the
requirements of a connection have only focussed on incorporating a DA
(forwarding) label. Further, these forwarding labels only need to be
distinct in resolving some number (N say) of different client layer
(link-connection) instances within a server layer (network connection)
resource partition. However, there are advantages from having both a SA
and DA label in a co-ps traffic unit that are network unique and not
just link-connection unique (ie not swapped)....the inherent robustness
under misconnectivity defects (without any adjunct OAM flow) is one of
these. And of course, these are the nature of the native labels one
already gets in Ethernet due to its cl-ps mode origins. So why would
one even contemplate not using these since they are already there?

The VID label is slightly different in that one can consider it as a
'route discriminator label' and a local extension to the SA or DA, ie it
provides the ability to identify disjoint paths between nodal end
points.

The mere fact IEEE may not refer to the above quantities as 'labels'
does not change the fact that this is what they are. So I'm not clear
what your real point is here.

regards, Neil



Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when.