Subject: Re: bridging over mpls

From: Kireeti Kompella <[email-masked]>
Date: Sat, 20 Nov 1999 10:32:43 -0800 (PST)

> (and i guess also the architecture i-d) seem to preclude bridging of
> layer 2 packets over mpls lsps:

Thanks, Juha, for bringing this up -- this hadn't occurred to me.

...

> it this intentional?  i need to be able to bridge ethernet packets over
> mpls lsps.

Absolutely.  I concur.

>    This means that the identity of the network layer protocol
>    must be inferable from the value of the label which is popped from
>    the bottom of the stack, possibly along with the contents of the

Why "network layer protocol"?  If the tail end knows what to do with
the packets (by whatever means of coordinating with the head end), why
dictate that there must be a network layer below the last label?
Something less restrictive like

     The nature of the packet must be inferrable from the value of the
     last label.

where 'inferrable' means either directly inferrable, or agreed upon
by the head and tail ends (and the 'agreement' could be to look at
a SNAP header, or to treat this as a layer 2 packet, ...).

Kireeti.

---

From: Kireeti Kompella <[email-masked]>
Date: Sat, 20 Nov 1999 11:00:05 -0800 (PST)

> In the case of bridging, I would assume that the entire packet that
> needs to be bridged (including its Layer 2 header) would constitute the
> payload of the MPLS packet.

Not necessarily.  For example, the ingress and egress could agree on
a mapping of <dest mac address, src mac address> -> label.  The
tunneled packet could then be stripped of the mac addresses.  The
egress LSR then resurrects the mac addresses based on the label.

This is possibly a far-fetched example, but there are practical
applications of similar techniques.  The point is not to restrict
the contents of the packet beyond the last label to a network
layer, or a fully-formed layer 2 packet, or anything.

...
> This requires that the egress
> LSP know that what is coming off the LSP is bridged Ethernet traffic.

That's the key: if the ingress and egress LSRs are agreed on the
contents of the packet past the last label, everything is hunky dory.

Kireeti.

---

From: Shahram Davari <[email-masked]>
Date: Tue, 23 Nov 1999 09:21:07 -0800

Hi,

I also agree with Juha that besides configuration, a Protocol ID (SNAP) in
signaling or as data encapsulation should be introduced as a possible
option.

Regards,
Shahram

> -----Original Message-----
> From: Juha Heinanen [mailto:[email-masked]]
> Sent: Monday, November 22, 1999 3:45 PM
> To: Adrian Farrel
> Cc: Kireeti Kompella; [email-masked]; [email-masked]
> Subject: RE: bridging over mpls
> 
> 
> 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.
> 
>  > 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.
> 
> -- juha
>

---

From: "David Allan" <[email-masked]>
Date: Tue, 23 Nov 1999 12:43:24 -0500

Adrian:

> From:	Adrian Farrel [SMTP:[email-masked]]
> Sent:	Tuesday, November 23, 1999 12:31 PM
> To:	Juha Heinanen
> Cc:	[email-masked]
	<snip>

> Yes, although we can probably limit ourselves to OUI and PID rather than
> using the full BLLI construct.
> 
Don't dismiss the utility of the L2 and L3 components in the BLLI. The
ability to specify both protocol and encap (or various permuations such as
NULL encap or multiple protocols LLC muxed etc.) is useful and fosters
interoperable solutions.

cheers
Dave