Dimitri,
As Neil correctly pointed out, there is a great
advantage in having connection source ID within label of every packet
forwarded over the connection (and MPLS’s great deficiency is the lack of
LSP source ID in the MPLS label).
NH=> Yes, it is true that
having a SA label in each/every traffic unit is an important advantage...and so
is having a DA address label (for forwarding) that does not have to be
swapped. As I pointed out before, one can take some short-cuts
and traditional co-ps mode technologies have (perhaps unconsciously?) done
so, viz:
- if one respects the requirements of a
connection then you can omit the SA label from the DP traffic units....as
under defect-free conditions it is redundant information. However,
this means OAM (essentially a CV flow that contains the SA label) should
(but really ought to be must for customer integrity/security reasons) be run
on ALL connections (irrespective of their importance) as one cannot predict
a priori where misconnectivity defects will occur. But this is
significantly operationally inferior to having the SA information carried in
the traffic unit as this makes the network inherently robust to such defects
without any OAM at all.
- wrt
forwarding one only needs to resolve/identify (ie label) the number of
client instances that a given server layer resource partition can support
per client link connection.....noting that said labels are indeed
indirection proxies for the true DA anyway. However, this is also
operationally inferior to using a true connection DA for forwarding
that is not swapped.
Now if you don't respect the
requirements of a connection, and both LDP and PHP in MPLS don't as they
create mp2p constructs, then you have to appeal to a higher layer entity to
effect a demerging function, ie essentially recover the lost SA
information. If the client is a cl-ps mode technology with
non-overlapping addresses this can do the job directly. If this is not
the case you have to add the lost information some other way....and in MPLS
this is done by adding a further 1-hop LSP where the label here now takes on
the semantic of SA. But this is actually not a very sensible approach
because one of the key operational things we need in any layer network is
consistent Characteristic Information (ie consistent traffic unit structure,
consistent traffic unit functional field semantics and consistent
OAM). Why is this important? Well, if one has misconnectivity
defects present it is important that the trail (co mode) or flow (cl mode)
termination points handles the traffic units and OAM in a consistent and
predictable way. MPLS does not have consistent CI....indeed I can list
at least 4 different semantics of a label and more will emerge as folks
consider new applications like p2mp constructs.
There are many other consequences
of merging constructs, but I don't want to get into these
here.
regards, Neil
The
source ID must be within the (data plane) label and not anywhere else,
because the label constitutes Layer Information (LI) in ITU terms, and only
LI is accessible to a server layer that claims transparency for its clients.
On the other hand source MA in co Ethernet is not used for packet
forwarding, hence it should not be signaled as a part of the (control plane)
label, which is information that must be put by an upstream node into the
packet header, so that the downstream node could recognize and properly
forward the packet.
The conclusions in the context of co Ethernet:
<!--[if
!supportLists]-->a)
<!--[endif]-->Data plane label is something determined
only by IEEE, because it exists independently from any Control Plane:
Ethernet connections could be configured by NMS without any Control Plane
(no control plane labels at all). As far as CCAMP is concerned, data plane
label is untouchable;
<!--[if
!supportLists]-->b)
<!--[endif]-->Control plane label is always a subset of
data plane and is an essential subject of CCAMP discussions: is it DMAC/VID?
just VID? nothing as in case of statically configured
connections? Is it network-scope? node-scope? link-scope? Stuff like
that.
Cheers,
Igor
<!--[if
!supportLineBreakNewLine]-->
<!--[endif]-->
>
So, IMO IEEE should be responsible for the definition of data
> plane
labels, while CCAMP for control plane labels.
a label distribution
protocol is a set of procedures by which one node
informs another of the
label/FEC bindings it has made
if these labels are distributed via
the gmpls control plane driving
population of the LIBs to which
difference are u pointing out here ? so,
not sure to see the point
(whatever the number of levels of indirection
between the fwd'ing plane
encoding and control plane encoding u will
always fall back on the
former, the label distribution protocol
exchanges a piece of information
used by the nodes to perform their
forwarding decision)
-d.
> -----Original Message-----
> From: Igor
Bryskin [mailto:i_bryskin@yahoo.com]
> Sent: Friday, September 07,
2007 9:21 PM
> To: neil.2.harrison@bt.com; PAPADIMITRIOU Dimitri;
> adrian@olddog.co.uk; zali@cisco.com;
>
Attila.Takacs@ericsson.com; ccamp@ops.ietf.org; gels@rtg.ietf.org
>
Cc: rcallon@juniper.net
> Subject: 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
> >
ions/222> to see what's on, when.
>