Subject: RE: New MPLS Charter?

From: [email-masked]
Date: Wed, 6 Dec 2000 09:53:03 -0000

>   I can see how a literal interpretation of item 3) could cause problems.
> Being pragmatic let me suggest that we insert an indication that both
> implicit
> and explicit labels are part of the charter.
> 
>   I believe the literal interpretation that George is referring to is
> "explicit labels" and indeed if we are limited to explicit labels GMPLS
> is homeless. I am sure that is not the intention of the wording because
> it clearly talks about implicit label switching like wavlength and space
> so simply adding the words "implicit and explicit" should solve the
> problem.
NH=> Peter,  Implicit and explicit labels as you call them are not at all
the same thing from an architectural perspective.  In 'pure' MPLS we have an
enity called the shim-header.  So what we are talking about here is the
*user-plane* and, if it was understood better, the creation of a new layer
network each time a shim (characteristic information) label header is added
(I am using functional arch terminology which many manufacturers and
operators are familar with).  The 'implicit' labels on the other hand are
actually substitutional terms which, in essence, mean nothing more than
'technology specific'.......though I know they are dressed-up in the
'Generalised MPLS' philosophy which, in its purest sense, is simply a
statement of a desire to use a single control-plane over all technologies,
and clearly has nothing at all to do with labels and the user-plane.

I think this distinction.......ie explicit labels => user-plane, implicit
labels => control-plane philosophy.....are so far removed from each other
there is no relationshiop between them.

Neil

---

From: "Peter Ashwood-Smith" <[email-masked]>
Date: Wed, 06 Dec 2000 09:05:37 -0500

If you take a look at the actual implementations of different cross
connects you will find that they have backplane control functions
that look something like this:

  Photonic:
  connect(<input fiber>, <output fiber>)

  TDM:
  connect(<input fiber>[<timeslots>], <output fiber>[<timeslots>]

  ATM:
  connect(<input port>/<vcc>, <output port>/<vcc>)

  PPP LSRs
  connect(<input port>/<shim>, <output port>/<shim>)

  etc...

  In essense you can use a single traffic engineering implementation to
control all of these devices with little changes between implementations.
There is not much more of a (high level control plane) stretch from shim 
header switching to photonic switching than there was from shim to ATM.
Infact there are a number of people that have extended PNNI so that it
can control a photonic switch. 

  Anyway I obviously disagree with you ;) but we can happily argue this
next week. What I don't understand is why there was no complaining earlier
this year or last year when we were first talking about this stuff.

  Cheers,

  Peter

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 06 Dec 2000 06:29:08 -0800

Neil,
 
> enity called the shim-header.  

The shim-header is just *one* of the options, but not the only one
possible. MPLS also supports carrying labels in VCI/VPI and DLCI.

> So what we are talking about here is the

The GMPLS technology has to do with the concept of "label swapping" as a
forwarding paradigm. So, it has a lot to do with labels.
  
Yakov.

---

From: Yangguang Xu <[email-masked]>
Date: Wed, 06 Dec 2000 11:31:20 -0500

Yakov,

I am totally confused. I thought we were only looking to have GMPLS for control
plane. Label swapping is done in data plane. What's the "label" after a LSP
being set up in circuit switched transport network? 

Below are my understanding of MPLS control plane concepts that can be "mapped"
to circuit switched transport network. Given that circuit paths are
service-driven, one possible understanding is to treat the service request as an
FEC. It contains next hop (or destination address for hop by hop routing) and
incoming physical interface (e.g., if negotiation is not required at connection
creation time) or path constraints (e.g., if negotiation is required). Because
labels are used for traffic forwarding, they are analogous to cross connect ID.
Label binding is then conceptually equivalent to choosing cross-connection
across the switch matrix. 
 
An alternate interpretation (a more popular way )can be constructed as follows:
In circuit switched networks, setting up a LSP means making cross connects along
the desirable path. Labels are used to determine cross connect configurations.
Assuming a non-blocking switch fabric, determining a cross-connect means
determining external ingress and egress physical interfaces. So labels are used
to indicate specific physical interfaces. Label binding entails choosing the
correct ingress or egress interface according to path selection decision and
local policies. 
 
In both of the above interpretations, making cross connects is equivalent to
writing to a label switching forwarding table. After the path is set up, user
traffic simply follows the dedicated physical path (cross connect). The concepts
below elaborate on the second interpretation. 

Thanks,

Yangguang