Subject: [mpls-tp] MPLS-TP over Ethernet?

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 8 Sep 2008 19:32:03 +0300

Hi all,
I have a question (probably a somewhat naive one) regarding MPLS-TP.
This question is based on the following assumptions:

 1.  MPLS-TP will run over Ethernet
    *   While I cannot find a direct reference, this assumptions look reasonable to me
    *   I also assume that such links between adjacent MPLS-TP boxes can pass thru some kind of IEEE 802.1 bridges, the latter remaining unaware about MPLS-TP.
 2.  MPLS-TP will use the MPLS forwarding paradigm without any changes.
    *   AFAIK, this has been the rationale behind the request to use the MPLS protocol numbers for T-MPLS that has become MPLS-TP
    *   Combined with the previous assumption it means that, in the case of P2P LSPs, MPLS packets will be encapsulated into unicast Ethernet frames with the DMAC set to the MAC address of the peer Ethernet port of the "next hop" MPLS-TP box
 3.  MPLS-TP must be able to operate without congruent IP.
    *   This has been stated too many times on this list so I just take it as given
    *   IMHO it implies that MPLS-TP must be able to run over Ethernet links without relying on ARP to find out what is the MAC address of the peer port.

Hence my question: How will an MPLS-TP "learn" MAC address of the peer port of the next hop box?

Of course this address can be manually configured when an MPLS-TP LSP is set up.
IMHO the problem with this answer is that the life span of MAC addresses is usually bound to that of suitable equipment units (line cards or, possibly, boxes). I.e., if the equipment unit to which the MAC address has been bound is replaced, the LSP has to be reconfigured to become operational.

Using some "well-known multicast" (or broadcast) address as the DMAC would IMHO mean a deviation from the MPLS forwarding paradigm.

Developing a new kind of ARP is probably possible but IMO would require an additional reserved label to identify the protocol messages.

I am not aware of any other alternatives. Do I miss something? Has this issue ever been raised in the T-MPLS  or MPLS-TP discussions?

Regards,
  Sasha

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 8 Sep 2008 15:41:03 -0400

Sasha,

I don't that has been discussed to date. I think the assumption is
that there's not going to be an Ethernet layer under MPLS-TP - it'll
run over G.709 or GFP framing (using the MPLS codepoint, presumably).

However, if it were to run over pt.-pt. Ethernet links, as you noted,
the MAC addresses at the two ends could be provisioned, or we could
use Reverse ARP (RFC 903). A box can send a RARP request with its own
MAC address in ar$sha and leave the three other protocol fields
undefined. The response will have both MAC addresses filled in (ar$sha
and ar$tha), so both endpoints now know the MAC addresses at both ends
of the link. The two IP address fields can be ignored for this
application.

Cheers,
Andy

On Mon, Sep 8, 2008 at 12:32 PM, Alexander Vainshtein
<[email-masked]> wrote:
> MPLS-TP will run over Ethernet
>
> While I cannot find a direct reference, this assumptions look reasonable to
> me
> I also assume that such links between adjacent MPLS-TP boxes can pass thru
> some kind of IEEE 802.1 bridges, the latter remaining unaware about MPLS-TP.
>
> MPLS-TP will use the MPLS forwarding paradigm without any changes.
>
> AFAIK, this has been the rationale behind the request to use the MPLS
> protocol numbers for T-MPLS that has become MPLS-TP
> Combined with the previous assumption it means that, in the case of P2P
> LSPs, MPLS packets will be encapsulated into unicast Ethernet frames with
> the DMAC set to the MAC address of the peer Ethernet port of the "next hop"
> MPLS-TP box
>
> MPLS-TP must be able to operate without congruent IP.
>
> This has been stated too many times on this list so I just take it as given
> IMHO it implies that MPLS-TP must be able to run over Ethernet links without
> relying on ARP to find out what is the MAC address of the peer port.
>
> IMHO the problem with this answer is that the life span of MAC
> addresses is usually bound to that of suitable equipment units (line cards
> or, possibly, boxes). I.e., if the equipment unit to which the MAC address
> has been bound is replaced, the LSP has to be reconfigured to become
> operational.
>
> Using some "well-known multicast" (or broadcast) address as the DMAC would
> IMHO mean a deviation from the MPLS forwarding paradigm.
>
> Developing a new kind of ARP is probably possible but IMO would require an
> additional reserved label to identify the protocol messages.
>
> I am not aware of any other alternatives. Do I miss something? Has this
> issue ever been raised in the T-MPLS  or MPLS-TP discussions?
>
> Regards,
>   Sasha
>
>
>
>
>
>
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 8 Sep 2008 15:42:21 -0400

Whoops, I meant the three other address fields, not the three other
protocol fields.

Cheers,
Andy

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 9 Sep 2008 08:39:05 +0300

Andy,
Lots of thanks for a prompt and highly informative response.

I agree that RARP looks like a resonable solution (better than static provisioning).

Regards,
     Sasha

________________________________________
From: Andrew G. Malis [[email-masked]]
Sent: Monday, September 08, 2008 10:42 PM
To: Alexander Vainshtein
Cc: [email-masked]; Andrew Sergeev; Jeremy Brayley
Subject: Re: [mpls-tp] MPLS-TP over Ethernet?

Cheers,
Andy

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 9 Sep 2008 08:49:27 +0300

Su Hui,
Lots of thanks for a prompt response.

It may be a matter of interpretation, but my impression from the discussion on this list has been that at least MPLS-TP-capable links would not be always assigned with IP addresses.
On fact, one of the substantial lacunae in the MPLS-TP concept is, IMO, lack of ANY explicitly defined addressing scheme.

So you probably cannot always use ARP on these links.

On the other hand, RARP can be used on P2P Ethernet links (as indicated by Andy). I am still not sure what happens if there is an Ethernet bridge between a pair of adjacent (at the MPLS-TP layer)  MPLS-TP boxes.

Regards,
     Sasha
________________________________
From: [email-masked] [[email-masked]]
Sent: Tuesday, September 09, 2008 4:51 AM
To: Alexander Vainshtein
Cc: Andrew Sergeev; Jeremy Brayley; [email-masked]; [email-masked]
Subject: 答复: [mpls-tp] MPLS-TP over Ethernet?

Hi Sasha,

The requirement is “It MUST be possible to operate and configure the MPLS-TP data (transport) plane without any IP functionality.”
I think it means that data plane does not support IP functionality，but control plane and manage plane can support IP functionality. So ARP can be used to find out the Peer port’s MAC address if MPLS-TP is running over a Ethernet link.
Regards,
SU Hui.

        Alexander Vainshtein <[email-masked]>
发件人： [email-masked]

2008-09-09 00:32

        收件人：        "[email-masked]" <[email-masked]>
        抄送：        Andrew Sergeev <[email-masked]>, Jeremy Brayley <[email-masked]>
        主题：        [mpls-tp] MPLS-TP over Ethernet?

Hi all,

Regards,
  Sasha

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 09 Sep 2008 08:41:29 +0200

Sasha,
 
The physical media of MPLS-TP can be 
- SDH
- OTN
- PDH
- 802.3
as described in G.8112 http://www.itu.int/rec/T-REC-G.8112-200610-I/en. As
specified in clause 6.2.2.1/G.8112 "The MAC DA is the MAC address of the
T-MPLS next hop's interface or the broadcast MAC address.". As it is a p2p
physical media you can use as DA value the MAC address of the peer port or
you can use the broadcast MAC address.
 
As an alternative, you could learn the MAC address of the peer port by
reading the SA value in the received frames and insert this value in the DA
field of the outgoing frames. I.e. this is a method that is specified in
802.1ah, clause 26.4.1, second paragraph for p2p backbone service instance
connections.

Note that the use of 802.3 (ethernet) as physical media does not imply that
"MPLS-TP will run over Ethernet" in the sense that "links between adjacent
MPLS-TP boxes can pass thru some kind of IEEE 802.1 bridges". I.e. a 10G,
40G or 100G MPLS-TP NNI signal will pass thru an 802.1 bridge. Such signal
will pass thru an OTN switch.
 
When operator A deploys a MPLS-TP network and has to connect to a network
termination device located behind the network of operator B, then when
operator B deploys an Ethernet transport network either an MPLS-TP LSP
Tunnel, or MPLS-TP Section connection signal will be carried thru the
ethernet transport network of operator B as a MPLS-TP type customer service
to connect the network termination device with the operator A edge node.
 
In operator B's network edge the MPLS-TP (tunnel or section) signal is
mapped into a service VLAN and then transported to the other end of the
operator B network. When the MPLS-TP section signal is to be forwarded, the
802.3/PDH/SDH physical media signal between operator A and B is terminated
and the MPLS-TP section signal is extracted and mapped into the service
VLAN. When the MPLS-TP tunnel signal is to be forwarded, the 802.3/PDH/SDH
physical media signal and the MPLS-TP section signal between operator A and
B are terminated and the MPLS-TP tunnel signal is extracted and mapped into
the service VLAN.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alexander Vainshtein
Sent: 08 September 2008 18:32
To: [email-masked]
Cc: Andrew Sergeev; Jeremy Brayley
Subject: [mpls-tp] MPLS-TP over Ethernet?

Hi all,

*	While I cannot find a direct reference, this assumptions look
reasonable to me 

*	I also assume that such links between adjacent MPLS-TP boxes can
pass thru some kind of IEEE 802.1 bridges, the latter remaining unaware
about MPLS-TP.

*	AFAIK, this has been the rationale behind the request to use the
MPLS protocol numbers for T-MPLS that has become MPLS-TP 

*	Combined with the previous assumption it means that, in the case of
P2P LSPs, MPLS packets will be encapsulated into unicast Ethernet frames
with the DMAC set to the MAC address of the peer Ethernet port of the "next
hop" MPLS-TP box

*	This has been stated too many times on this list so I just take it
as given 

*	IMHO it implies that MPLS-TP must be able to run over Ethernet links
without relying on ARP to find out what is the MAC address of the peer port.

Hence my question: How will an MPLS-TP "learn" MAC address of the peer port
of the next hop box?
 
Of course this address can be manually configured when an MPLS-TP LSP is set
up.  
IMHO the problem with this answer is that the life span of MAC addresses is
usually bound to that of suitable equipment units (line cards or, possibly,
boxes). I.e., if the equipment unit to which the MAC address has been bound
is replaced, the LSP has to be reconfigured to become operational. 

 
 
Regards,
  Sasha

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 9 Sep 2008 11:04:44 +0100

Hi Sasha,

[SNIP]

> It may be a matter of interpretation, but my
> impression from the discussion on this list
> has been that at least MPLS-TP-capable links
> would not be always assigned with IP addresses.

I *think* that if we operate a control plane, we must assign "IP 
identifiers". That may be IP addresses or unnumbers. In this respect, the 
data plane links are no different from any other technology transport link 
controlled by GMPLS.

Note that if IP addresses are assigned they do not need to be routable in 
the control plane (and certainly not in the data plane). If unnumbers are 
assigned, the TE router ID is likely to be used as the IP address component 
of the unnumber, and that *is* routable in the control plane (but not in the 
data plane).

This is business as usual for GMPLS.

OTOH, if there is no control plane, all you have to do is assign identifiers 
that are suitable for the management system. One could argue that since it 
is new equipment being rolled out to support MPLS-TP, any consistent naming 
scheme will do, and selecting one that is useful if a control plane is later 
installed (i.e., IP numbers or unnumbers) would be wise.

Cheers,
Adrian

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 9 Sep 2008 14:27:32 +0300

Maarten,
Please see inline below (magenta italics).

Regards,
    Sasha

________________________________
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, September 09, 2008 9:41 AM
To: Alexander Vainshtein; [email-masked]
Cc: Andrew Sergeev; Jeremy Brayley
Subject: RE: [mpls-tp] MPLS-TP over Ethernet?

Sasha,

The physical media of MPLS-TP can be
- SDH
- OTN
- PDH
- 802.3
as described in G.8112 http://www.itu.int/rec/T-REC-G.8112-200610-I/en. As specified in clause 6.2.2.1/G.8112 "The MAC DA is the MAC address of the T-MPLS next hop's interface or the broadcast MAC address."
[[Sasha]] IMO the latter option breaks the MPLS forwarding paradigm.
  As it is a p2p physical media you can use as DA value the MAC address of the peer port or you can use the broadcast MAC address.
[[Sasha]] Does that imply that passing thru 802.1 bridges is explicitly prohibited?  I do not remember ever seeing any such prohibition.

As an alternative, you could learn the MAC address of the peer port by reading the SA value in the received frames and insert this value in the DA field of the outgoing frames. I.e. this is a method that is specified in 802.1ah, clause 26.4.1, second paragraph for p2p backbone service instance connections.
[[Sasha]]  IMHO this cannot work even in a P2P case: why should your peer send anything to you?

Note that the use of 802.3 (ethernet) as physical media does not imply that "MPLS-TP will run over Ethernet" in the sense that "links between adjacent MPLS-TP boxes can pass thru some kind of IEEE 802.1 bridges". I.e. a 10G, 40G or 100G MPLS-TP NNI signal will pass thru an 802.1 bridge. Such signal will pass thru an OTN switch.[[Sasha]]  Again, if this is an absolute restriction for MPLS-TP, it should better be explicitly specified.

When operator A deploys a MPLS-TP network and has to connect to a network termination device located behind the network of operator B, then when operator B deploys an Ethernet transport network either an MPLS-TP LSP Tunnel, or MPLS-TP Section connection signal will be carried thru the ethernet transport network of operator B as a MPLS-TP type customer service to connect the network termination device with the operator A edge node.

In operator B's network edge the MPLS-TP (tunnel or section) signal is mapped into a service VLAN and then transported to the other end of the operator B network. When the MPLS-TP section signal is to be forwarded, the 802.3/PDH/SDH physical media signal between operator A and B is terminated and the MPLS-TP section signal is extracted and mapped into the service VLAN. When the MPLS-TP tunnel signal is to be forwarded, the 802.3/PDH/SDH physical media signal and the MPLS-TP section signal between operator A and B are terminated and the MPLS-TP tunnel signal is extracted and mapped into the service VLAN.
[[Sasha]] To me, the two paragraphs above seem to be orthogonal to the use case I've presented.
Regards,
Maarten

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein

Hi all,

Regards,
  Sasha

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 09 Sep 2008 15:58:18 +0200

Sasha,
 
See inline, marked [mv].
Regards,
Maarten

  _____  

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: 09 September 2008 13:28
To: Maarten Vissers
Cc: Andrew Sergeev; Jeremy Brayley; [email-masked]
Subject: RE: [mpls-tp] MPLS-TP over Ethernet?

Maarten,
 
Regards,
    Sasha

  _____  

Sasha,
 
The physical media of MPLS-TP can be 
- SDH
- OTN
- PDH
- 802.3
as described in G.8112 http://www.itu.int/rec/T-REC-G.8112-200610-I/en. As
specified in clause 6.2.2.1/G.8112 "The MAC DA is the MAC address of the
T-MPLS next hop's interface or the broadcast MAC address."
[[Sasha]] IMO the latter option breaks the MPLS forwarding paradigm. 
  As it is a p2p physical media you can use as DA value the MAC address of
the peer port or you can use the broadcast MAC address.
[[Sasha]] Does that imply that passing thru 802.1 bridges is explicitly
prohibited?  I do not remember ever seeing any such prohibition.
[mv] Normally you do not pass a bridge with a MPLS-TP NNI signal. The
Ethernet part is just a Physical Media layer for MPLS-TP, and should be
terminated at the end of the fiber. So the Ethernet piece, including the DA
field, just passes the fiber. Any 802.3 interface port accepts frames with
DA=broadcast address as valid frame. As such the use of the braodcast
address is the most logical address on a p2p 802.3 physical media
connection.
 
[mv] For the case someone wants to carry the MPLS-TP signal carried over an
802.3 PHY as an EVC service through an Ethernet bridged network, the use of
the broadcast address is not an issue at all. The EVC service is a
point-to-point service. It is a port-based service, and thus just carries a
single untagged VLAN. At the edge of the ethernet network this port-based
(untagged VLAN) service is mapped into a Service VLAN in a Provider Edge
Bridge (case of PB network) or into a BAckbone SErvice Instance (BSI) in an
I-component Backbone Edge Bridge (case of PBB network). In p2p Service VLANs
the forwarding is done only on the S-VID (and not on the DA); the value in
the DA field is ignored in p2p VLANs. In a p2p BSI the cusotmer MAC freame
(from the MPLS-TP interface port) is encapsulated into a BAckbone MAC frame.
The p2p nature of the BSI causes the B-DA field to carry the B-SA value
present in the B-SA field of the received B-MAC frames. 
If you carry such MPLS-TP NNI signal as an EVC service, the MPLS-TP NNI port
is an Ethernet Customer Edge (CE) port. Such Ethernet CE port should be
equipped with ETH MEP function supporting ETH OAM. I don't think that any
one intents to add ETH MEP functions to MPLS-TP interface ports.

As an alternative, you could learn the MAC address of the peer port by
reading the SA value in the received frames and insert this value in the DA
field of the outgoing frames. I.e. this is a method that is specified in
802.1ah, clause 26.4.1, second paragraph for p2p backbone service instance
connections.
[[Sasha]]  IMHO this cannot work even in a P2P case: why should your peer
send anything to you?  
[mv] Your peer will always send OAM to check the status and performance of
the NNI (case of MPLS-TP interface) or the service instance (case of PBB
BSI). But as long as you did not receive the first frame from your peer, you
insert the broadcast address (case of MPLS-TP interface) or the BSI Group
Address (case of PBB BSI). MAC addresses have relevance only within the
scope of their VLAN. Such VLAN can be untagged or tagged (C-, S-, I-tag) or
labelled (VPLS=MPLS label stack entry tagged VLAN). A p2p VLAN does not need
to make any decision to which output port to forward an incoming frame;
there is only one output port and all incoming frames must be delivered to
that output port. 

Note that the use of 802.3 (ethernet) as physical media does not imply that
"MPLS-TP will run over Ethernet" in the sense that "links between adjacent
MPLS-TP boxes can pass thru some kind of IEEE 802.1 bridges". I.e. a 10G,
40G or 100G MPLS-TP NNI signal will pass thru an 802.1 bridge. Such signal
will pass thru an OTN switch.[[Sasha]]  Again, if this is an absolute
restriction for MPLS-TP, it should better be explicitly specified.  

[[Sasha]] To me, the two paragraphs above seem to be orthogonal to the use
case I've presented. 
[mv] is my EVC service example representing your use case?
 
Regards,
Maarten

  _____  

Hi all,

 

 
 
Regards,
  Sasha