[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) and have
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 protocol
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
configurations.

Efforts are underway to add multi-region capability to VLSR, where we can have
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 L2SC path,
could be established to provide the missing link for the PSC request.

 Regards,
 - Bijan


Quoting dimitri papadimitriou <dpapadimitriou@psg.com>:

igor

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)

Before
explaining how cool/elegant it could be provisioned
via GMPLS you need to answer IMO the following
questions:

-> 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
standards.

-> 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
switch

-> 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
forwarding tables?

-> 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 ?

Cheers,
Igor

  --- dimitri papadimitriou <dpapadimitriou@psg.com>
wrote:


hi igor,

[snip - hint: igor i suggest you create a thread on
control vs management plane]


My view wrt Ethertnet GMPLS is this. I have no 

doubts

that we can come up with mechanisms to dynamically
provision L2SC LSPs.


ouf ;-)


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 

after

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


only

after that design and develop ways to provision 

them

dynamically.

i am not sure to follow how are you going to
determine the benefit from dynamic provisioning by statically configure these
LSPs ?


In other words, it is wiser to repeat what has 

been

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... ?


Cheers,
Igor




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


holds

in a *traffic*
carrying cl-ps  IP network, esp when this is in


the

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


OOB

data-plane network
that carries the control/management-plane


protocols.


These were points I wanted to make.....hopefully
I've done a better job
this time.

regards, Neil



-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: 23 July 2005 00:08
To: Harrison,N,Neil,IKM1 R
Cc: ccamp@ops.ietf.org
Subject: Re: Ethernet Control Plane [Was: Re:
Frameformat in a l2cs
gmpls rnvironment.]


Hi Neil,

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


plane".

I mean a control plane which:
- uses IP as its network protocol
- uses IP addresses to identify control plane
resources
- uses IP addresses to identify data plane


resources

within the control plane
- uses protocols developed for use in the


Internet.


I am not questioning IP as a cl-ps networking

protocol *carrying*
a signalling protocol (RSVP-TE, or dare I mention

PNNI, or any
signalling protocol yet to be invented) or a

routing protocol
(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 

here....and also


on the self-assumed importance of a 

control-plane.

Hint: It ain't
that important.....the management-plane (which 

may

be using IP!)
however is. 


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
management plane.
It may be that you believe that CCAMP is willfully
neglecting the
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 http://mail.yahoo.com .