Subject: RE: bridging over mpls

From: Adrian Farrel <[email-masked]>
Date: Tue, 23 Nov 1999 17:30:44 -0000

OK,
We seem to be in agreement here.

> 
> Adrian Farrel writes:
> 
> > If my ingress sets up two tunnel LSPs one for IP traffic 
> > and one for (say)
> > tunneled Ethernet (or IPX, or Voice) how will the egress 
> > know which tunnel
> > is which?  How will it know how to handle the payload?
> 
> the contents (either a single protocol or an encapsulation 
> mechanism) of
> the lsp needs to be told when the lsp is setup via signaling.
> 
> > It seems to me that this is an important part of the 
> > signaling protocol for
> > MPLS.
> 
> exactly.
> 
> > In RSVP it is possible to supply the protocol identifier 
> > of the encapsulated
> > layer 3 traffic.  This is a start, but does it provide 
> > enough information
> > for all cases?
> > 
> > In CR-LDP the protocol identifier cannot be passed.
> 
> indicating the contents of lsp should be part of ldp itself, 
> not rsvp or
> cr-ldp, since it has nothing to do with constraints, explicit 
> routing, or
> traffic engineering.

Yes, you're right, it applies to LDP too.  In other words, lsp setup needs
this information regardless of the label distribution protocol in use.

> > We could introduce a SNAP header to the signaling flow 
> > (which, I think is
> > what Juha was suggesting) or to the data packets or both.
> 
> see how it is done in atm signaling using the low layer protocol
> information element.

Yes, although we can probably limit ourselves to OUI and PID rather than
using the full BLLI construct.

Having reached this level of agreement about need and implementation, what
is the next step?

Regards,
Adrian

--
Adrian Farrel  mailto:[email-masked]
ATM, MPLS and Telecoms Development Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 23 Nov 1999 20:45:52 +0200 (EET)

> Having reached this level of agreement about need and implementation, what

the mpls label stack encoding i-d should be edited to explicitly allow
mpls packets to carry anything.

then someone should write a "multiprotocol encapsulation over mpls" i-d
unless the encap i-d can't simply refer to rfc1483.

finally, the signaling protocol i-ds, such as the ldp i-d, should be
extended to include indication of the protocol or multiplexing method of
the lsp.

-- juha