The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2006-Apr> msg00100



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[mpls] consolidated response to Q12/15 on T-MPLS

  • From: "Brungard, Deborah A, ALABS" <dbrungard@att.com>
  • Date: Mon, 24 Apr 2006 16:41:49 -0500
  • Cc: mpls@ietf.org
  • Thread-Index: AcZmwhhFcDbL9nphRtC/6+Si+HeSHwA6s/8g
  • Thread-Topic: [mpls] consolidated response to Q12/15 on T-MPLS
  • X-Env-Sender: dbrungard@att.com
  • X-MIME-Autoconverted: from quoted-printable to 8bit by cell.onecall.net id k3OLiFH20651
  • X-Msg-Ref: server-3.tower-120.messagelabs.com!1145914737!10803720!32
  • X-Originating-IP: [134.24.146.4]
  • X-StarScan-Version: 5.5.9.1; banners=-,-,-
  • X-VirusChecked: Checked

Also client processing is different - T-MPLS has T-MPLS client-specific
processes (Section 7 lists clients as IP, Ethernet, ATM, MPLS, T-MPLS).
The new amendment to G.8010 (unfortunately not liaisoned) clearly shows
two different processes (e.g. Ethernet/MPLS, Ethernet/T-MPLS). 

Having here a weekend of rainy weather with time to read, T-MPLS
features are listed in section 6.1, including:
- supports bidirectional LSPs
- supports control channel separation
- supports only Y.1720 protection switching (ITU's 1+1 scheme based on
sequence numbers)

To me, it "looks" somewhat like GMPLS (and similar application -
transport equipment), though it's labeled MPLS, and supports different
functionality than MPLS or GMPLS. The control plane is tbd. It is
difficult to comment if it is a subset of MPLS (or GMPLS) - without a
clear statement of the requirements and understanding of the
modifications to the "superset".

Especially interesting will be e-2-e operations when Figure 5's "foreign
TMPLS network" is present in a not-so-clean scenario of cloudy networks.

Deborah

-----Original Message-----
From: Scott W Brim [mailto:swb@employees.org] 
Sent: Sunday, April 23, 2006 6:37 AM
To: Andrew G. Malis
Cc: mpls@ietf.org
Subject: Re: [mpls] consolidated response to Q12/15 on T-MPLS

On 04/23/2006 03:36 AM, Andrew G. Malis allegedly wrote:
> So, I guess we need to know whether or not the T-MPLS equipment will
do
> any MPLS-layer processing of the packets, or simply transparently
> transport them without inspection or change, and what signaling (if
any)
> would be used across this interface.

That's the plan as far as I know, but I don't think it has been
completely spelled out.

Another interesting scenario is where a device has both "full" MPLS and
T-MPLS LSPs on the same interface.

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls