[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ethernet Control Plane [Was: Re: Frameformat in a l2cs gmpls rnvironment.]
While we are on the subject of control vs. management plane and the need for
GMPLS-based control of Ethernet TE, I thought it might be worthwhile to
indicate some prior work done in this area and within the context of an
experimental optical and IP network (although a few of you might be familiar
with this activity, as my colleagues or myself might have shared with you the
goal of the project which also involves establishing Ethernet/L2 LSPs).
As part of this project (referred to as DRAGON, initiated in the early 2003
and supported by the NSF), we have implemented the GMPLS capabilities (OSPF-TE
& RSVP-TE) within an element (referred to as the Virtual LSR, or VLSR)
used it within experimental and demo networks to control Ethernet, TDM and
Fiber-switched capable switches. The implementation is open source software,
available free to public and it runs on FreeBSD or Linux.
While VLSR participates in a GMPLS-based control network from one end, it
enables the devices (Ethernet switches, cross-connects, etc. without GMPLS
capability) to participate within the network, by translating specific
events into an appropriate sets of commands for the device to effect an
associated state change.
In our use of VLSR to control Ethernet switches, the LSP set up requests are
processed by issuing the appropriate SNMP commands to the said device to place
two ports into a single VLAN effecting a port-to-port cross-connect. For
control of Ethernet switches, we have used RFC 2674 to dynamically modify VLAN
Efforts are underway to add multi-region capability to VLSR, where we
the ability to route light-paths across different networks
transparently. A case
of interest there is to cater to the PSC LSP when no existing path to the
destination might exist, however a lower layer path, say an Ethernet
could be established to provide the missing link for the PSC request.
Quoting dimitri papadimitriou <firstname.lastname@example.org>:
What I was trying to say here is that for the User how
TE Ethernet connection is established - via control or
management planes is of a little importance.
-> in the CCAMP context where the second C means "Control" it is of
importance because the purpose of this working group is to define IP
control plane mechanism(s)
explaining how cool/elegant it could be provisioned
via GMPLS you need to answer IMO the following
-> i suggest you also take a look to section 3 and 4 and if you think
there are additional arguments you would consider as part of these
sections i would suggest that you share them with us
1) What does it mean Traffic Engineered Ethernet
connection in the data plane and what is it good for?
For instance, we perfectly understand what does ATM
connection or TDM connection mean in the data plane
and can provide references to corresponding data plane
-> i suggest you take a look at scenario 2 for inst. that should in
principle provide an answer to your question
2) How does the label-aware Ethernet forwarder
co-exist with other Ethernet forwarders on the same
-> it is an explicit non-objective of THIS document to detail
(existing) Ethernet forwarding behaviour and their co-existence, in
part. due to point 3) here below
3) What information is necessary to provision the
-> the current document refers to "label" entries without delving
into details but this has been done purposely as the choice which
will ultimately be made (e.g. VLAN Tags, or new TPIDs or something
else) is orthogonal to be capabilities this working group wants to
achieve with GMPLS control of Ethernet networks
And so on.
-> in practice ?
--- dimitri papadimitriou <email@example.com>
[snip - hint: igor i suggest you create a thread on
control vs management plane]
My view wrt Ethertnet GMPLS is this. I have no
that we can come up with mechanisms to dynamically
provision L2SC LSPs.
My problem is the order of events. It does not seem to me wise to
come up with
some control plane framework and solution(s) and
that think what we need to do in the data plane.
actually, if this is the only problem you have, i
should underline we do not have to initiate the definition of a specific
forwarding paradigm so i am not necessarily sure about what you mean by the
last part of the above sentence
It seems to me wiser to learn how to statically
provision such LSPs, see how useful they are, and
after that design and develop ways to provision
i am not sure to follow how are you going to
determine the benefit from dynamic provisioning by statically
In other words, it is wiser to repeat what has
done with TDM LSPs.
wiser ? ... would you clarify ? don't you think it
is more appropriate to receive feedback on the appropriateness of the
use of GMPLS for the scenarios depicted in the problem statement document
rather than digress on non-rational argument such as "wiser", "careful"
or so... ?
A control-plane is useful in the major co-cs
transport networks (mainly
for S-PVCs and resilience) but its a minor player
compared to role of
the management-plane. The converse of course
in a *traffic*
carrying cl-ps IP network, esp when this is in
context of the
public Internet.....but of course this isn't the
case here and IP is
only being used as the transport protocol in the
that carries the control/management-plane
These were points I wanted to make.....hopefully
I've done a better job
From: Adrian Farrel [mailto:firstname.lastname@example.org] Sent: 23 July 2005 00:08
To: Harrison,N,Neil,IKM1 R
Subject: Re: Ethernet Control Plane [Was: Re:
Frameformat in a l2cs
I think John beat me off the blocks here, but...
GMPLS assumes an IP control plane.
An IP control-plane? There is actually no such
animal. Just what
the heck does that REALLY mean in GMPLS say?
Let me explain.
Perhaps I should have said "IP-based control
I mean a control plane which:
- uses IP as its network protocol
- uses IP addresses to identify control plane
- uses IP addresses to identify data plane
within the control plane
- uses protocols developed for use in the
I am not questioning IP as a cl-ps networking
a signalling protocol (RSVP-TE, or dare I mention
PNNI, or any
signalling protocol yet to be invented) or a
(OSPF or ISO or whatever)
I am glad to hear it.
or even management protocols
Fine, but not in the remit of CCAMP.
but an 'IP Control Plane' per se means absolutely
nothing to me....
Well, I think it should. I think the list of
attributes that I have
given above define a control plane based on IP. It is undoubtable
that attempts have been made to
use control planes
based on other protocols. Some have been highly
successful. Some have
been less fortunate.
...nor should it to anyone else.
I think folks who were around at the beginning of
CCAMP and who were
part of the debate with the IESG will be very
familiar with where the
IETF draws the line here.
I think some folks might need a reality check
on the self-assumed importance of a
Hint: It ain't
that important.....the management-plane (which
be using IP!)
I am not sure how to interpret this.
It may be that you think that control plane is bad
per se, but you have
said elsewhere that you think it has value - but
much less than the
It may be that you believe that CCAMP is willfully
management plane. This would, in fact, be true. It
is not in CCAMP's
=== message truncated ===
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around