Subject: [mpls-tp] An Inband Data Communication Network For the MPLS Transport Profile

From: Dieter Beller <[email-masked]>
Date: Wed, 04 Feb 2009 22:37:43 +0100

Hi all,

please be informed that we submitted the following I-D a few days ago
that

addresses the control plane and management plane in-band communication

requirements described in draft-ietf-mpls-tp-requirements-03:

draft-beller-mpls-tp-gach-dcn-00

This new draft defines how the Generic Associated Channel (G-ACH) can be

extended in order to provide an in-band management communication channel

(MCC) and a signaling communication channel (SCC). These communication

channels are intended to constitute part of the data communication
network

(DCN). It shall be noted that dedicated channels are defined for the

management communication (MCN) and the signaling communication network

(SCN - for control plane purposes), which allows a full separation of
the two.

Review comments on the I-D are solicited.

There is still an unresolved issue in the initial version of this I-D:
for identifying

the payload of the MCC or SCC G-ACH packet, a protocol ID (PID) field
has been

defined - alternatively, a TLV based approach may be possible.

Thoughts on this are welcome.

Thanks,

Dieter and Adrian

[email-masked]
wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title : An Inband Data Communication Network For the MPLS Transport Profile
Author(s) : D. Beller, A. Farrel
Filename : draft-beller-mpls-tp-gach-dcn-00.txt
Pages : 7
Date : 2009-01-19

A Generic Associated Channel (G-ACH) has been defined as an extension
of the pseudowire Associated Channel Header (ACH) to enable the
realization of a control/communication channel associated with
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs),
MPLS pseudowires (PWs), MPLS LSP segments, and MPLS sections between
adjacent MPLS-capable devices.

The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS
architecture that identifies elements of the MPLS toolkit that may be
combined to build a carrier grade packet transport network based on
MPLS packet switching technology.

This document describes how the G-ACH may be used to provide the
infrastructure that forms part of the Management Communication
Network (MCN) and a Signaling Communication Network (SCN).
Collectively, the MCN and SCN may be referred to as the Data
Communication Network (DCN). The document explains how MCN and SCN
packets are encapsulated, carried on the G-ACH, and demultiplexed for

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-beller-mpls-tp-gach-dcn-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--

---

From: <[email-masked]>
Date: Thu, 5 Feb 2009 13:00:48 -0000

Thanks Dieter/Adrian,
 
I have a few observations on this draft.

1    I truly think it is high time we came clean on PWs wrt MPLS-TP.
Putting it quite bluntly, the requirements that must be met to define a
'carrier class transport profile' of MPLS are such that the drivers that
led to PWs in the original form of MPLS are gone, ie LDP merging and IP
pkts for CP/MP arriving on same DP interface as MPLS pkts.  If PWs are
kept in MPLS-TP they MUST IMO revert back to their original adaptation
role and not become multi-hop entities, since this will create a further
co-ps mode layer network above MPLS-TP to design/operate/manage....which
kind-of negates the whole purpose of doing MPLS-TP in the first place.
 
Now I know this observation is more general than your draft, but I think
we should start to comes to terms with this in *all* the MPLS-TP drafts.
IMO this should actually be a stated requirement of MPLS-TP, ie don't
create another co-ps mode (PW) layer network above MPLS-TP.
 
Can I therefore ask if what I am saying here is
understood/agreed......and if not, then I'd to also hear the technical
reasons why not.

2    Can you please explain what this sentence (from the abstract)
means:
"It should be noted that the use of the G-ACH to provide connectivity
for the DCN is intended for use only where the MPLS-TP network is not
capable encapsulating or delivering native DCN messages."
 
I suspect you mean you can use another different layer network for the
OOB CP/MP.  For example since there always has to be another real
transport network below MPLS-TP in order to 'put bits of the wire' we
could use this as the section layer OOB CP/MP MPLS-TP comms
channel.......though IMO the general case should always use a special
label reserved label (like the GAL = label value 13) for this purpose.

3    In the Introduction section it says:
 
"The generalized  concept is referred to as the Generic Associated
Channel (G-ACH) and  is intended to create a control/communication
channel associated with  the LSP that can be used to carry packets used
for OAM and similar functions (e.g. control plane messages)."
 
Strictly speaking this is not correct, as we should not be carrying DP
OAM used to detect/handle DP defects in the logical (OOB channel of the)
CP/MP network.  Defect detection/handling OAM should look like normal
traffic and only exist in the DP.
 
I am aware of discussions in the MEAD team that could allow this to be
done correctly.  For example, one proposal I am aware of is to make the
BOS (ie S=1) MPLS-TP header carry an Ethertype instead of a label when
carrying DP traffic......here the EXP and TTL fields could be set as
zero (or some other value TBD) as they have no need to be used.  This
means we could also use this same BOS (ie S=1) to carry OAM and signify
this by a different (TBD) value in the EXP and TTL fields.  Here both
traffic and OAM have exactly the same header structures (which is what
we want so that traffic and OAM looks the same), and we could then use
the GAL (label 13) purely for the logically OOB CP/MP
functions.....which is nice clean DP and CP/MP separation in the
labelling.
 
I think this is an excellent idea and so I hope it gets serious
consideration.

regards, Neil  

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Dieter Beller
	Sent: 04 February 2009 21:38
	To: [email-masked]
	Subject: [mpls-tp] An Inband Data Communication Network For the
MPLSTransport Profile

	Hi all,
	
	please be informed that we submitted the following I-D a few
days ago that
	addresses the control plane and management plane in-band
communication
	requirements described in draft-ietf-mpls-tp-requirements-03:
	
	draft-beller-mpls-tp-gach-dcn-00
<http://www.rfc-editor.org/cgi-bin/iddoctype.pl?letsgo=draft-beller-mpls
-tp-gach-dcn-00> 
	
	This new draft defines how the Generic Associated Channel
(G-ACH) can be
	extended in order to provide an in-band management communication
channel
	(MCC) and a signaling communication channel (SCC). These
communication
	channels are intended to constitute part of the data
communication network
	(DCN). It shall be noted that dedicated channels are defined for
the
	management communication (MCN) and the signaling communication
network
	(SCN - for control plane purposes), which allows a full
separation of the two.

	There is still an unresolved issue in the initial version of
this I-D: for identifying
	the payload of the MCC or SCC G-ACH packet, a protocol ID (PID)
field has been
	defined - alternatively, a TLV based approach may be possible.

	Thanks,
	Dieter and Adrian
	
	[email-masked] wrote: 

		A New Internet-Draft is available from the on-line
Internet-Drafts directories.
		
			Title           : An Inband Data Communication
Network For the MPLS Transport Profile
			Author(s)       : D. Beller, A. Farrel
			Filename        :
draft-beller-mpls-tp-gach-dcn-00.txt
			Pages           : 7
			Date            : 2009-01-19
		
		A Generic Associated Channel (G-ACH) has been defined as
an extension
		of the pseudowire Associated Channel Header (ACH) to
enable the
		realization of a control/communication channel
associated with
		Multiprotocol Label Switching (MPLS) Label Switched
Paths (LSPs),
		MPLS pseudowires (PWs), MPLS LSP segments, and MPLS
sections between
		adjacent MPLS-capable devices.
		
		The MPLS Transport Profile (MPLS-TP) is a profile of the
MPLS
		architecture that identifies elements of the MPLS
toolkit that may be
		combined to build a carrier grade packet transport
network based on
		MPLS packet switching technology.
		
		This document describes how the G-ACH may be used to
provide the
		infrastructure that forms part of the Management
Communication
		Network (MCN) and a Signaling Communication Network
(SCN).
		Collectively, the MCN and SCN may be referred to as the
Data
		Communication Network (DCN). The document explains how
MCN and SCN
		packets are encapsulated, carried on the G-ACH, and
demultiplexed for

		
		
		Below is the data which will enable a MIME compliant
mail reader
		implementation to automatically retrieve the ASCII
version of the
		Internet-Draft.

________________________________

		_______________________________________________
		I-D-Announce mailing list
		[email-masked]
		https://www.ietf.org/mailman/listinfo/i-d-announce
		Internet-Draft directories:
http://www.ietf.org/shadow.html
		or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

	-- 
	
________________________________

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 5 Feb 2009 14:11:23 -0000

Neil,

> understood/agreed......and if not, then I'd to also hear the technical

Your observations about MPLS-TP in general MUST [RFC2119] be addressed in 
the context of the requirements and frameworks drafts. We cannot have the 
discussions in any other context, and other I-Ds will continue to follow on 
from those drafts until such time as the basic architecture and requirements 
are changed.

I have tried for some time to raise questions about the way in which 
pseudowires are included in the MPLS-TP work, but it is not for me to drive 
the solution arrived at by the community. It is clear that a requirement for 
MPLS-TP is to be able to emulate link connectivity for non-MPLS networks by 
use of MPLS network connections. So PWs are in scope in some way.

I don't think repeated reference to MPLS merging is particulalry relevant. 
It is not included in MPLS-TP in any way.

The references to LDP are peripheral. No-one is proposing using LDP in its 
normal MPLS usage for IP prefix-based label distribution. Whether LDP 
continues to be used as the end-to-end coordination protocol for PW setup is 
perhaps open for discussion, but what we have in existence at the moment 
does the job.

> label reserved label (like the GAL = label value 13) for this purpose.

We were considering, for example, the ability of the network to deliver IP 
packets without applying an MPLS shim.

Whatever you say, you will continue to find interfaces that are capable of 
delivering MPLS and IP packets "in parallel." For example, Ethernet 
interfaces.

> traffic and only exist in the DP.

We did not say "all OAM packets."

Consider that switchover requests, event notifications, etc. are also OAM 
messages.

We could debate all day about whether these are control plane or data plane 
messages. I am not sure that is helpful!

> I think this is an excellent idea and so I hope it gets serious

Thanks.

Adrian

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 05 Feb 2009 16:07:17 +0100

Neil,
 
In
http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/best-mpls-tp-oam-pdu
-formats-02.ppt (also at
http://www.maartenvissers.nl/mplstp/best-mpls-tp-oam-pdu-formats-02.ppt)
illustrates in slides 16, 19 and 22/23 header structures for OAM/comms and
data packets. You can compare side-by-side the packet differences between
OAM/comms and non-OAM. Note that the difference between an OAM and a comms
packet is the channel type value (or OpCode value in Ethernet VLAN/VPLS).
The headers used to identify OAM and non-OAM packets of a PW [or VPLS, or
LSP] are the same.
 
If you look at the
http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/mpls-tp-protocol-typ
es-00.ppt (also at http://www.maartenvissers.nl/mplstp/
<http://www.maartenvissers.nl/mplstp/mpls-tp-protocol-types-00.ppt>
mpls-tp-protocol-types-00.ppt
<http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/mpls-tp-protocol-ty
pes-00.ppt> ) then you find a definition of MPLS-TP PW and LSP Protocol
Types using today's fields in the MPLS frames. 
 
It also illustrates that the GAL introduces unnecessary complexity and
should from a protocol perspective be removed from the packets. with
exception of a Section LSP OAM packet that is carried unlabelled over the
PHY. 
 
The G-ACH/GAL **do not** create an OOB CP/MP channel; the G-ACH (like the
ACH and CW) create a consistent MPLS-TP protocol type, and the GAL is an
unnecessary complexity that we should remove from the OAM packets and
relabel as "priority label" to be used in unlabelled packets carried over a
PHY.
 
We must distinguish between a channel carrying information and its usages as
OOB or IB. The channel can be used in an OOB mode or in an IB mode; this
choice is controlled by the application using the channel. It is possible to
deploy today's IP over PHY comms channel or IP over LSP comms channel as an
OOB channel; i.e. use it as a DCC like we have in STM-N.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: donderdag 5 februari 2009 14:01
To: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] An Inband Data Communication Network For
theMPLSTransport Profile

Thanks Dieter/Adrian,

1    I truly think it is high time we came clean on PWs wrt MPLS-TP.
Putting it quite bluntly, the requirements that must be met to define a
'carrier class transport profile' of MPLS are such that the drivers that led
to PWs in the original form of MPLS are gone, ie LDP merging and IP pkts for
CP/MP arriving on same DP interface as MPLS pkts.  If PWs are kept in
MPLS-TP they MUST IMO revert back to their original adaptation role and not
become multi-hop entities, since this will create a further co-ps mode layer
network above MPLS-TP to design/operate/manage....which kind-of negates the
whole purpose of doing MPLS-TP in the first place.
 
Now I know this observation is more general than your draft, but I think we
should start to comes to terms with this in *all* the MPLS-TP drafts.  IMO
this should actually be a stated requirement of MPLS-TP, ie don't create
another co-ps mode (PW) layer network above MPLS-TP.
 
Can I therefore ask if what I am saying here is understood/agreed......and
if not, then I'd to also hear the technical reasons why not.

2    Can you please explain what this sentence (from the abstract) means:
"It should be noted that the use of the G-ACH to provide connectivity  for
the DCN is intended for use only where the MPLS-TP network is not capable
encapsulating or delivering native DCN messages."
 
I suspect you mean you can use another different layer network for the OOB
CP/MP.  For example since there always has to be another real transport
network below MPLS-TP in order to 'put bits of the wire' we could use this
as the section layer OOB CP/MP MPLS-TP comms channel.......though IMO the
general case should always use a special label reserved label (like the GAL
= label value 13) for this purpose.

"The generalized  concept is referred to as the Generic Associated Channel
(G-ACH) and  is intended to create a control/communication channel
associated with  the LSP that can be used to carry packets used for OAM and
similar functions (e.g. control plane messages)."
 
Strictly speaking this is not correct, as we should not be carrying DP OAM
used to detect/handle DP defects in the logical (OOB channel of the) CP/MP
network.  Defect detection/handling OAM should look like normal traffic and
only exist in the DP.
 
I am aware of discussions in the MEAD team that could allow this to be done
correctly.  For example, one proposal I am aware of is to make the BOS (ie
S=1) MPLS-TP header carry an Ethertype instead of a label when carrying DP
traffic......here the EXP and TTL fields could be set as zero (or some other
value TBD) as they have no need to be used.  This means we could also use
this same BOS (ie S=1) to carry OAM and signify this by a different (TBD)
value in the EXP and TTL fields.  Here both traffic and OAM have exactly the
same header structures (which is what we want so that traffic and OAM looks
the same), and we could then use the GAL (label 13) purely for the logically
OOB CP/MP functions.....which is nice clean DP and CP/MP separation in the
labelling.

regards, Neil  

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dieter Beller
Sent: 04 February 2009 21:38
To: [email-masked]
Subject: [mpls-tp] An Inband Data Communication Network For the
MPLSTransport Profile

Hi all,

please be informed that we submitted the following I-D a few days ago that
addresses the control plane and management plane in-band communication
requirements described in draft-ietf-mpls-tp-requirements-03:

draft-beller-mpls-tp-gach-dcn-00
<http://www.rfc-editor.org/cgi-bin/iddoctype.pl?letsgo=draft-beller-mpls-tp-
gach-dcn-00> 

This new draft defines how the Generic Associated Channel (G-ACH) can be
extended in order to provide an in-band management communication channel
(MCC) and a signaling communication channel (SCC). These communication
channels are intended to constitute part of the data communication network
(DCN). It shall be noted that dedicated channels are defined for the
management communication (MCN) and the signaling communication network
(SCN - for control plane purposes), which allows a full separation of the
two.

There is still an unresolved issue in the initial version of this I-D: for
identifying
the payload of the MCC or SCC G-ACH packet, a protocol ID (PID) field has
been
defined - alternatively, a TLV based approach may be possible.

Thanks,
Dieter and Adrian

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : An Inband Data Communication Network For the MPLS
Transport Profile

	Pages           : 7

	Date            : 2009-01-19

Internet-Draft.

  _____  

[email-masked]

-- 

  _____

---

From: <[email-masked]>
Date: Thu, 5 Feb 2009 15:38:42 -0000

Thanks Adrian...a couple of clarifications are required here:
 
 AF wrote 05 February 2009 14:11
<snipped>
 
> I have tried for some time to raise questions about the way 
> in which pseudowires are included in the MPLS-TP work, but it 
> is not for me to drive the solution arrived at by the 
> community. It is clear that a requirement for MPLS-TP is to 
> be able to emulate link connectivity for non-MPLS networks by 

NH=> OK, but 'in which way'?.....see my remark below.
> The references to LDP are peripheral. No-one is proposing 
> using LDP in its normal MPLS usage for IP prefix-based label 
> distribution. Whether LDP continues to be used as the 
> end-to-end coordination protocol for PW setup is perhaps open 
> for discussion, but what we have in existence at the moment 
> does the job.

NH=> But you have side-stepped my key point here Adrian, ie we should
not be creating a further co-ps PW layer network above MPLS-TP...as that
would  defeat the whole purpose of MPLS-TP IMO.  I assume you must agree
on the sense of this?  And if this is not correctly captured in the
MPLS-TP requirements document than I would propose it should be.  To be
very clear...PWs must revert back to their orginal adaptation role and
not become a networked entity in MPLS-TP.

Ben...can you help me out on this one?

<snipped>

> 
> Whatever you say, you will continue to find interfaces that 
> are capable of delivering MPLS and IP packets "in parallel." 
> For example, Ethernet interfaces.

NH=> This is not correct.  Ethernet carries a PID field (Ethertype) that
quite clearly separates "the serial" delivery of client traffic units.
Moreover, in Ethernet the layer network characteristic information is
consistent, this is not the case for vanilla MPLS.

regards, Neil

---

From: Dieter Beller <[email-masked]>
Date: Thu, 05 Feb 2009 17:52:01 +0100

Hi Neil,

some of the discussion seems to be a bit off-topic (which is the
in-band DCN).

So, I'm only responding to the issue closely related to this I-D.

[email-masked] wrote:

<snip>

regards, Neil

As Adrian mentioned, there are server layers that can carry MPLS-TP
which

also provide means to separate the MPLS user traffic from CP/MP traffic.

Examples are (see also section 7.1.2.3.1 in G.7712 from 2008):

Ethernet has different Ethertypes for MPLS, IP, and OSI PDUs
(CP/MP

traffic uses the latter)

GFP for SONET/SDH/OTN  has different PTI values for MPLS, IP, and

IS-IS PDUs

The sentence in the I-D means that the G-ACH based SCC/MCC may not
always

be used (if, eg., already provided by the server layer).

I hope this clarifies the issue.

Cheers,

Dieter

--

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 05 Feb 2009 19:35:49 +0000

Colleagues,

> Ben...can you help me out on this one?

I refer my learned colleagues to the MPLS-TP requirements draft. At no point
does the draft state that PWs have to be part of any solution.  In fact
there are only two places where PWs are mentioned at all - firstly in the
definitions section where we have related the definitions of segment/etc. To
LSP and PW equivalents to enable better understanding by IETF participants
of the intended meaning of the terms we use and in requirement 3

   3   Mechanisms and capabilities MUST be able to interoperate, without
       a gateway function, with existing IETF MPLS [RFC3031] and IETF
       PWE3 [RFC3985] control and data planes where appropriate.

Which really is saying if you're going to use MPLS and/or PWs don't depart
away from the base architectures in an incompatible manner in the way T-MPLS
started to.

The requirements in this space are as Adrian stated to be able to emulate
link connectivity for client networks by use of MPLS network connections. We
make no judgement in the requirements as to the appropriate solution to meet
those requirements.

Alternative solutions to PWs are permissible by the requirements. Use of
only SS-PW are permissible by the requirements. Use of MS-PW are permissible
by the requirements.  The decision is one of solution design, not
requirements capture.  However the one thing I would say is for
non-greenfield MPLS-TP deployments some form of migration strategy away from
the PWs used in those networks would need to be formulated before an
alternative solution was deployable. For greenfield MPLS-TP deployments the
world is your oyster.

Ben

Ben