MPLS WG has a liaison on T-MPLS

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

It's been pointed out to me that some folk in CCAMP might not be following
the MPLS mailing list too closely.

The MPLS working group has received the liaison below from the ITU-T with
respect to three Recommendations that have been produced on "Transport
MPLS" known as T-MPLS.

T-MPLS appears to be the use of some of the facilities of an MPLS data
plane in order to construct a packet-based transport network. Although no
work on the control plane has been started, we may see this a prime
candidate for GMPLS since the GMPLS protocol family is tuned for transport
networks and supports MPLS packet data planes.

Your review input on these documents is welcomed and should, in the first
instance, be sent to the MPLS working group who are putting together a
coordinated response.

Cheers,
Adrian

----- Original Message ----- 
From: "Greg Jones (ITU-T SG 15)" <tsbsg15@itu.int>
To: "George Swallow" <swallow@cisco.com>; "Loa Andersson" <loa@pi.se>
Cc: <mpls@lists.ietf.org>; <mark.jones@sprint.com>;
<maeda@ansl.ntt.co.jp>; <info@mfaforum.org>; <Ghani.Abbas@marconi.com>;
<sbrim@cisco.com>; <fenner@research.att.com>; <statements@ietf.org>;
<rcallon@juniper.net>; <tsbsg15@itu.int>; <betts01@nortel.com>
Sent: Sunday, April 02, 2006 8:59 PM
Subject: [mpls] New Liaison Statement, "T-MPLS Consented Recommendations"


>
> Title: T-MPLS Consented Recommendations
> Submission Date: 2006-04-02
> URL of the IETF Web page:
https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=207
> Please reply by 2006-04-17
>
> From: Greg Jones(ITU-T SG 15) <tsbsg15@itu.int>
> To: IETF MPLS WG, CC: MFA Forum(George Swallow <swallow@cisco.com>, Loa
Andersson <loa@pi.se>)
> Cc: info@mfaforum.org
> maeda@ansl.ntt.co.jp
> sjtrowbridge@lucent.com
> rcallon@juniper.net
> fenner@research.att.com
> sob@harvard.edu
> sbrim@cisco.com
> mpls@lists.ietf.org
> Reponse Contact: tsbsg15@itu.int
> Technical Contact: Ghani.Abbas@marconi.com
> mark.jones@sprint.com
> betts01@nortel.com
> Purpose: For action
> Body: We apologize for not having sent a liaison regarding three
consented Recommendations related to
> T-MPLS. The intent of these Recommendations is not to change MPLS but
rather to identify a
> subset of existing MPLS necessary and sufficient to provide
connection-oriented packet transport.
> The approach to the work was to make a profile of the MPLS data plane
functionalities defined in
> IETF RFCs using the description of MPLS provided in G.8110 (which was
approved last year).
> The intended application of this profile is to provide a
connection-oriented packet transport
> network.
> The focus of the three new recommendations is on the data plane aspects
of T-MPLS. Control plane
> aspects are currently for further study and the work on this subject is
starting.
> According to our work methodology the T-MPLS definitions are split into
the three main
> Recommendations that have been consented in February 2006:
> * G.8110.1 dealing with the T-MPLS Architecture
> * G.8112 dealing with T-MPLS interface specification
> * G.8121 dealing with T-MPLS equipment functional specification
> A brief high-level introduction of the essential features and selected
options for Transport MPLS
> can be found in section 6/G.8110.1.
> The objective of the work done by ITU-T SG15 was to define a way to use
MPLS as a connection-
> oriented packet-based transport solution for packet aware transport
networks that can support both
> packet and circuit (e.g. SDH, OTH or WDM) switching technologies under a
common operation,
> control and management paradigm. For this purpose T-MPLS deploys the
MPLS frame format,
> Client to MPLS mapping and MPLS to MPLS multiplexing and complements
this with transport
> network OAM (Y.1711), nested connection monitoring requiring the labels
to be present up to the
> final node in the network, protection switching (Y.1720/G.8131),
transport network based control
> and management planes, maintaining frame ordering and a restricted
number of classes of
> service/queues.
> * MPLS has many applications and it is desirable to identify a subset of
MPLS technology that
> provides the necessary and sufficient functionality for transport
applications.
> We have indicated below some of the options we have selected :-
> * In IETF RFCs the usage of PHP is optional. We decided not to use it in
order to simplify OAM
> procedures
> * In IETF RFCs the usage of merging is optional. We decided not to use
it in order to simplify
> OAM procedures and also because the relative lower number of LSPs to be
supported is not
> considered a major scaling issue
> * The usage of ECMP is optional. We decided not to use it in order to
simplify OAM procedures
> * Leaving labels 16-31 for further study was seen as a no change because
the label allocation on a
> link is defined in IETF RFCs as a local matter for any MPLS device.
> We are not expecting that the current version of the specification is
going to create any
> interoperability issue. We envisage two possible cases of
interoperability:
> 1. Interoperability between a T-MPLS box and an existing full-featured
and fully configurable
> MPLS box can be solved by configuring the MPLS box to use the same
options selected by T-
> MPLS (T-MPLS being a profile of MPLS this should be possible). In this
case the link between
> the two boxes is a T-MPLS link and in the scope of our Recommendations.
> 2. Interoperability between a transport platform supporting T-MPLS and
an existing MPLS box
> that uses a different option selection than T-MPLS, should be solved by
the transport platform.
> In this case the link between the transport platform and the MPLS box is
not a T-MPLS link and
> therefore it is outside the scope of T-MPLS recommendations. We are
looking for cooperation
> with IETF to develop the detailed specification of this case.
> Please find attached the text of the consented Recommendations.  Please
note that some minor
> modifications may be made to these draft Recommendations as a result of
comments made during
> the approval process
> We will appreciate your comments and suggestions in relation to the
initial scope of T-MPLS as a
> packet transport network technology.
> We are planning to review your comments during the next meeting that is
planned in Kobe (Japan)
> on 22-27 April 2006. Results of the comments will be included into our
future work (e.g. corrigenda
> or amendments) on T-MPLS Recommendations. Amendments of T-MPLS
Recommendations are
> already in our plan for the next SG15 plenary meeting in November
2006.We are looking forward
> for future cooperation with you in T-MPLS data plane and control plane
evolution.
>
> Attachments: Consented Text of G.8110.1, G.8112, G.8121
> Attachment(s):
>      Consented Text of G.8110.1
(https://datatracker.ietf.org/documents/LIAISON/file288.zip)
>      Consented Text of G.8112
(https://datatracker.ietf.org/documents/LIAISON/file289.zip)
>      Consented Text of G.8121
(https://datatracker.ietf.org/documents/LIAISON/file290.zip)
>
>
>
>
> _______________________________________________
> mpls mailing list
> mpls@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls
>
>