[Fwd: New Liaison Statement, "Clarification on the intended scope of T-MPLS"]
Loa Andersson <loa <at> pi.se>
2006-05-10 12:31:44 GMT
All,
we have received the included liaison from ITU-T SG 15.
Note that we've two slightly mixed discussion, one on MPLS and
another on pseudo wires. Try to direct comments to the appropriate
working group list.
we plan to give a formal response on May 17th, comments, both on
the content of this liaison and on the T-MPLS documentation, are
welcome.
Loa and George
-------- Original Message --------
Subject: New Liaison Statement, "Clarification on the intended scope of
T-MPLS"
Date: Thu, 04 May 2006 14:09:26 -0400
From: Greg Jones(ITU-T SG 15) <tsbsg15 <at> itu.int>
Reply-To: tsbsg15 <at> itu.int
To: George Swallow <swallow <at> cisco.com>, Loa Andersson <loa <at> pi.se>,
Stewart Bryant <stbryant <at> cisco.com>, Danny McPherson <danny <at> arbor.net>
CC: Scott Bradner <sob <at> harvard.edu>, Yoichi Maeda
<maeda <at> ansl.ntt.co.jp>, sjtrowbridge <at> lucent.com,
ghani.abbas <at> marconi.com, betts01 <at> nortel.com, tsbsg15 <at> itu.int,
greg.jones <at> itu.int, ghani.abbas <at> marconi.com, betts01 <at> nortel.com
Title: Clarification on the intended scope of T-MPLS
Submission Date: 2006-05-04
URL of the IETF Web page:
https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=218
From: Greg Jones(ITU-T SG 15) <tsbsg15 <at> itu.int>
To: IETF MPLS WG, PWE3 WG(George Swallow <swallow <at> cisco.com>, Loa
Andersson <loa <at> pi.se>, Stewart Bryant <stbryant <at> cisco.com>, Danny
McPherson <danny <at> arbor.net>)
Cc: Scott Bradner <sob <at> harvard.edu>
Yoichi Maeda <maeda <at> ansl.ntt.co.jp>
sjtrowbridge <at> lucent.com
ghani.abbas <at> marconi.com
betts01 <at> nortel.com
Reponse Contact: tsbsg15 <at> itu.int
greg.jones <at> itu.int
Technical Contact: ghani.abbas <at> marconi.com
betts01 <at> nortel.com
Purpose: For information
Body: Thank you for your informal feedback that has been provided on our
previous liaison statement on T-MPLS Consented Recommendations, we also
understand that you are in the process of developing a formal response.
To assist you in providing your formal response we would like to
provide some additional clarifications on the intended application of
T-MPLS.
Our intention in developing the suite of T-MPLS Recommendations was to
define a packet based transport network technology. The design
objectives of T-MPLS were:
a) Follow the principles of the transport network used in other ITU-T
defined transport technologies (e.g SDH, ATM, OTN).
b) To use the PDU and data plane processes defined by the IETF for MPLS.
T-MPLS is not intended to duplicate the functionality already provided
by IP/MPLS.
The only client fully described in the current version of G.8110.1 is
point to point Ethernet Virtual Connection (EVC). It was agreed to
revise the scope of the Recommendation and provide an appendix II
(attached) to reflect this. Some other key points identified were:
• The current version of G.8110.1 only defines the bearer plane and only
point to point trails are currently supported. It should be noted that
version 2 of G.8110.1 will add point to multipoint trails.
• Any interworking with client signals (e.g. MPLS, Ethernet) will be
client server i.e. any client OAM or control protocols will be tunneled
transparently across the T-MPLS layer network.
• Interworking between a client control plane and a (yet to be defined)
T-MPLS control plane will be addressed as a part of the control plane
architecture work.
• The T-MPLS network provides a single hop link to the client, it is
intended to offer a packet switched connection that has similar
operational characteristics to a SDH network providing a PDH link
connection, e.g. these connections must support the ability to activate
performance monitoring and fault management. Any PM data or failures
will be reported to the transport operations center.
We also note your comments on the usage of the label space terminology.
We will work to clarify and if necessary correct this in a future
revision.
We have also agreed to initiate work on the architecture of a control
plane for T-MPLS. We will use the ASON architecture to provide a
framework to describe the problem that is to be addressed. This does
not imply that we will specify an ASON control plane. Once we have
refined our requirements we will communicate them to you for advice on
how they may be addressed. If the requirements cannot be met by an
existing protocol suite we would like to work with you to develop the
appropriate enhancements.
We will be continuing our work on T-MPLS in particular the support of
other clients (e.g. IP/MPLS) at an interim meeting that is planned to be
held 19-23 June in Ottawa Canada. We will also address any comments
that you provide in your planned liaison statement. Any urgent changes
may be included in an amendment or corrigendum that could be consented
in October 2006. IETF experts are welcome to participate at this
meeting. Please contact betts01 <at> nortel.com by May 31st 2006 if you
should wish to participate.
G.8110.1 draft Appendix II
Support of IP/MPLS LSR based networks by
T-MPLS networks supporting point-to-point EVC services
When two IP/MPLS LSRs are connected via e.g. 802.3 interfaces to a
T-MPLS network, the T-MPLS network can provide an EVC service between
these two LSRs (nodes LSR A and LSR B in Figure II-1) to establish an
IP/MPLS link between these LSRs.
The IP/MPLS LSRs encapsulate their IP/MPLS packets into Ethernet frames
with or without VLAN Tag. These Ethernet frames are then transported via
802.3 interfaces to the T-MPLS network edge (nodes X and Y). At the
T-MPLS network edge the Ethernet signal is treated either as an
all-to-one EVC service or as one or more EVC and/or bundled EVC services
of which the frames are mapped into one or more T-MPLS (PW) trails and
then transported through the T-MPLS network.
In this network scenario the IP/MPLS routing and control plane adjacency
is between LSR A and LSR B. The T-MPLS network elements do not
participate in the IP/MPLS routing and control plane. A signalling
session that requests PHP is between LSR A and LSR B (T-MPLS nodes X and
Y are not involved).
Figure II-1/G.8110.1 – IP/MPLS via EVC over T-MPLS network
The functional model for this scenario is described in Figure II-2. The
atomic functions in the figure are specified in Recommendations G.8021
and G.8121.The IP/MPLS signals are carried through an IP/MPLS link
between LSR A and LSR B supported by an ETH trail between LSR A and LSR
B. The ETH trail is carried through a serial-compound ETH link supported
by an ETY trail interconnecting LSR A with T-MPLS PE X, a T-MPLS (PW)
trail interconnecting T-MPLS PE X with T-MPLS PE Y and an ETY trail
interconnecting T-MPLS PE Y with LSR B.
<<Figure II-2/G.8110.1 – Functional Model for IP/MPLS via EVC over
T-MPLS network>> - see attachment
Attachment(s):
Clarification on the intended scope of T-MPLS (see this WinWord
file for the diagrams)
(https://datatracker.ietf.org/documents/LIAISON/file311.doc)
--
--
Loa Andersson
Principal Networking Architect
Acreo AB phone: +46 8 632 77 14
Isafjordsgatan 22 mobile: +46 739 81 21 64
Kista, Sweden email: loa.andersson <at> acreo.se
loa <at> pi.se
_______________________________________________
mpls mailing list
mpls <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
RSS Feed