Subject: [mpls-tp] Requirement for data integrity

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 14 Dec 2008 14:57:10 -0000

Hi,

We have a requirement

>> 8) "MPLS-TP SHOULD support mechanisms which ensure the 
>> integrity of the transported customer's service traffic."

I wondered:

>> Is this "MUST NOT modify user traffic" or is it really a
>> request to provide integrity guarantees to the client layer?

Ben responds:

> I'm not sure.  I suspect the former. Does anyone have a view
> on this?

Anyone shed any light on the requirements for "integrity"?

Adrian

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 14 Dec 2008 22:39:23 +0200

Adrian, and all,
A similar requirement has been presented by a Tier 1 operator to the PWE3 WG some time ago, 
and RFC 4720 has been published to address it for frame-based traffic. 
I am aware of one implementation (for HDLC PWs), and I believe there was at least another one (for tagged Ethernet PWs).
But I have not heard about any deployments...

Regards,
	Sasha

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Sunday, December 14, 2008 4:57 PM
> To: [email-masked]
> Subject: [mpls-tp] Requirement for data integrity
> 
> Hi,
> 
> We have a requirement
>

---

From: <[email-masked]>
Date: Sun, 14 Dec 2008 21:22:47 -0000

I strongly suspect this *primarily* means transparency of all the client
DP/CP/MP traffic units at a binary (information) level, as this is the
key property that a client/server layer network relationship must
deliver.

Aside=> At a secondary level one can argue for integrity wrt protecting
the information transfer requirements of a either a message, file or
stream application.  However this *only* applies to a top-of-stack layer
network that supports message/file/stream end-system adaptation
functions.  If one is not top-of-stack then such applications should be
transparent to the server layer....the client of the server layer in
this case is another layer network that may or may not be top-of-stack
itself, and thus in this case case we are simply back to the previous
client/server transparency requirement.

Now when we are top-of-stack we have these additional transfer
requirements wrt 'integrity':
-	message....a single traffic unit, where mitigation of (binary)
information errors is the key consideration
-	file....a sequence of messages where, in addition to per traffic
unit error mitigation as above, we also have a requirement to preserve
traffic unit ordering
-	stream....like a file except that the temporal information of
traffic units in the sequence is also important and needs to be
preserved.

These impairments are mitigated by mechanisms in the end-system to 1st
layer network adaptations functions (eg CRC, Seq No., time stamp
respectively...CF UDP, TCP and RTP in IP).  Of course, there are limits
to the degree of network impairments that can be mitigated....and here
one needs to fully consider performance inheritance 'to the duct' (since
a link connection at layer N is a network connection at layer N-1, are
so on recurseively downwards to the duct).

regards, Neil

> [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
> Sent: 14 December 2008 20:39
> To: Adrian Farrel
> Cc: [email-masked]
> Subject: Re: [mpls-tp] Requirement for data integrity
> 
> Adrian, and all,
> A similar requirement has been presented by a Tier 1 operator 
> to the PWE3 WG some time ago, and RFC 4720 has been published 
> to address it for frame-based traffic. 
> I am aware of one implementation (for HDLC PWs), and I 
> believe there was at least another one (for tagged Ethernet PWs).
> integrity of 
> > >> the transported customer's service traffic."
> > 
> > I wondered:
> > 
> request to 
> > >> provide integrity guarantees to the client layer?
> > 
> > Ben responds:
> > 
> > > I'm not sure.  I suspect the former. Does anyone have a view on 
> > > this?
> >

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 15 Dec 2008 10:18:15 +0200

Neil,
Lots of thanks for a prompt response. My reading (which may be incorrect) of this response is

	integrity ~= transparency (+ some additional mechanisms in the case when we are "top of the stack")

However, I am not sure that this is also the position taken by the authors of the draft.
A brief scan indicates that:
- the term "transparency" does not appear at all in the text
- the term "integrity" appears 3 times:

1. As part of a general characterization of transport networks:
<quote>
	Another key characteristic of transport networks is the capability to maintain
	the integrity of the client across the transport network.
<end quote>

2. As part of the description of operation of the  transport network:
<quote>
	Server layer OAM is used to monitor the transport integrity of the client layer or client aggregate
<end quote>

3. In the requirement for mechanisms that ensure integrity of the transported customer's service traffic (quoted
in Adrian's original mail).

I do not feel that these statements (especially one about the server layer OAM) primarily mean "binary transparency".
IMHO and FWIW an explicit requirement of the client transparency AND en explicit clarification of the notion of integrity 
(e.g., following your guidelines) would be most helpful.

My 2c,
	Sasha

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Sunday, December 14, 2008 11:23 PM
> To: Alexander Vainshtein; [email-masked]
> Cc: [email-masked]
> Subject: RE: [mpls-tp] Requirement for data integrity
>

---

From: <[email-masked]>
Date: Mon, 15 Dec 2008 10:28:24 -0000

Thanks Sasha,

I do understand your concerns.  I suspect it's simply a matter that the
person who wrote 'integrity' was using it in some very general catch-all
sense.  But you are right that we should try and be a little more
precise as to what exactly is required.....so here is my view based on
the work we have been doing on G.800 (unified modelling).

However, I am going to copy-in Andy Reid so that he can check what I am
saying for accuracy and correct any mistakes/omissions I make....I am
sure there is a more optimal wording than I have used below, but I hope
this helps for now:

Client/server transparency means that each/every bit of the client
signal is treated equally by the server...and in particular the server
MUST NOT try and infer meaning from the client symbols, and for sure
MUST NOT attempt to change any of the client symbols.

A connection is key topological construct that has some important
properties (BTW - these properties are not simply of academic interest
but have a direct bearing on the design/operational complexity costs of
running networks):
-	A connection MUST only have a single source...so only p2p and
p2mp constructs can be called connections.
-	A connection MUST preserve the sequence ordering of client
symbols....a subtle corollary of this observation is that a connection
can only have a single QoS classification.
-	There MUST be no internal routing choice within a connection, ie
all symbols that enter a connection should appear on all the connection
egress points (with sequence ordering preserved).

Aside=> Of course the above can be compromised by network impairments.
But we can remove traffic load as a source of impairments...which is a
key consequence/requirement of a transport network using
connections....and to be very clear here:
-	it is NOT sufficient to simply provide reachability isolation
between different clients in a transport network client/server
relationship, we also need to provide performance isolation, ie the
traffic behaviour of client X cannot impact the performance experienced
by client Y.
-	A (server layer) connection is a *necessary* requirement to meet
this.  For *full-sufficiency* however the server layer resources should
also not be overbooked 

I would also like to observe that the OAM required to detect/handle
defects is quite independent of the above properties of a
connection....it is the above properties (and not OAM) that confers the
required 'integrity' of the information transfer.  Further, the OAM
required for co mode network connections is NOT the same as the OAM
required for cl-ps mode networks.  Example to prove why:  A connection
under defect-free operation is a constraining construct (to both traffic
and OAM PDUs).  However, if there is a misconnectivity defect present
the connection may no longer be operating as a constraining construct
and traffic can leak *unidirectionally* out of a connection *with no
return path*.  What this means is that OAM of a request/response nature
cannot be relied on in such cases, ie one cannot trace-out the leaking
traffic as the OAM request PDUs can leave the connection (at the point
of leaking) but will never return.  However, in a cl-ps mode network
request/response OAM is the correct type of OAM to use.

Hope that helps a bit more for now.

regards, Neil

> From: Alexander Vainshtein [mailto:[email-masked]] 
> Sent: 15 December 2008 08:18
> To: Harrison,N,Neil,CXM R
> Cc: [email-masked]; [email-masked]
> 	integrity ~= transparency (+ some additional mechanisms 
> in the case when we are "top of the stack")
> 
> 	Server layer OAM is used to monitor the transport 
> integrity of the client layer or client aggregate <end quote>
> 
> 3. In the requirement for mechanisms that ensure integrity of 
> the transported customer's service traffic (quoted in 
> Adrian's original mail).
> 
> I do not feel that these statements (especially one about the 
> server layer OAM) primarily mean "binary transparency".
> IMHO and FWIW an explicit requirement of the client 
> transparency AND en explicit clarification of the notion of 
> integrity (e.g., following your guidelines) would be most helpful.
> 
> My 2c,
> 	Sasha
> 
> 
> 
> 
> 
> 
> 
> > I strongly suspect this *primarily* means transparency of all the 
> > client DP/CP/MP traffic units at a binary (information) 
> level, as this 
> > is the key property that a client/server layer network relationship 
> > must deliver.
> > 
> > 
> > Aside=> At a secondary level one can argue for integrity wrt 
> > protecting the information transfer requirements of a either a 
> > message, file or stream application.  However this *only* 
> applies to a 
> > top-of-stack layer network that supports message/file/stream 
> > end-system adaptation functions.  If one is not 
> top-of-stack then such 
> > applications should be transparent to the server 
> layer....the client 
> > of the server layer in this case is another layer network 
> that may or 
> > may not be top-of-stack itself, and thus in this case case we are 
> > simply back to the previous client/server transparency requirement.
> > 
> > respectively...CF UDP, TCP and RTP in IP).  Of course, there are 
> > limits to the degree of network impairments that can be 
> > mitigated....and here one needs to fully consider performance 
> > inheritance 'to the duct' (since a link connection at layer N is a 
> > network connection at layer N-1, are so on recurseively 
> downwards to 
> > the duct).
> > 
> > regards, Neil
> > 
> > > A similar requirement has been presented by a Tier 1 
> operator to the 
> > > PWE3 WG some time ago, and RFC 4720 has been published to 
> address it 
> > > for frame-based traffic.
> believe there 
> > > was at least another one (for tagged Ethernet PWs).

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 17 Dec 2008 09:42:10 +0100

Neil,

> Client/server transparency means that each/every bit of the client signal
> is treated equally by the server...and in particular the server MUST NOT
> try and infer meaning from the client symbols, and for sure MUST NOT
> attempt to change any of the client symbols.

You have to start splitting the above into two parts:
1) bit/frame value, order and timing transparency
2) field snooping transparency.

The customer is requiring that its customer characteristic information (i.e.
its bits/frames) are passed through the network in a means that maintains in
a sufficient form the value, the order and the timing information of the
bits/frames applied at an input port of the network. In your terms "the
server will NOT attempt to change any of the client symbols".

In addition the customer is requiring that its bits/frames are delivered to
the intended output port of the network. 
- For the case there is only one output port the customer's characteristic
information does not need to identify this output port. 
- For the case all the customer's bits/frames must be output on multiple
output ports the customer's characteristic information does not need to
identify these output ports. 
- Only for the case the customer requires that some of its bits/frames are
output on port 1, some on port 2, some on port 3, etc it is necessary that
the customer's characteristic information includes in each frame an
identifier that allows the transport network to deliver each frame on one, a
subset or all of the output ports.

In the first two cases the network will pass through the customer
bits/frames without reading any of the fields in the customer's
characteristic information; i.e. the network doesn't snoop this
characteristic information... In your terms "server will NOT try and infer
meaning from the client symbols"

In the third case the network **must** read a field in the customer's
characteristic information in order to deliver each frame to the required
output port or output ports. In your terms "the server MUST infer meaning
from an egress port identifier field in the client symbols". 

>From a customer's perspective it does not matter if this reading of this
egress port identifier field (e.g. a destination address) is only read in
the adaptation function between the customer layer netowrk and the server
layer network, of if this egress port identifier field is read at one or
more points along the server layer trail. The customer is well aware that
such egress port identifier field is passed through "unchanged" and that the
network "will infer meaning from the value of this field"; i.e. "reading is
allowed, changing is not allowed".

Besides the customer's perspective and requirements a network has to deal
with the network's perspective and requirements. One of those requirements
is scalability. From a network scalability point of view it is important to
minimize the amount of state that a network has to support. As such it is
**beneficial** for a network (but **not mandatory**) to encapsulate the set
of egress port identifier values (e.g. source address, destination address)
within a customer's characteristic information. If such encapsulation is
deployed (e.g. MACinMAC), then the customer's egress port identifier fields
(e.g. SA, DA) are only read in the adaptation function between customer
layer and server layer, and within the server layer trail only the
associated network egress port identifier fields are read and their values
stored.

> A connection is key topological construct that has some important
properties
> (BTW - these properties are not simply of academic interest but have a
direct
> bearing on the design/operational complexity costs of running networks):
symbols....
>     a subtle corollary of this observation is that a connection can only
have
>     a single QoS classification.

This definition of "connection" is of no interest to running networks. This
definition is also showing why G.809 and the initial version of G.800 could
not be used as basis for the operation of transport networks. Let me
illustrate this below.

Transport networks deal with the set up, monitoring, protection of
"transport entities". Examples of such transport entities are: PDH 2 Mbit/s
p2p connection, PDH 45 Mbit/s p2p connection, PDH 34 Mbit/s p2p and p2mp
connections, SDH VC-n p2p and p2mp connections, ATM VP p2p and p2mp
connections, ATM VC p2p and p2mp connections, OTN ODUk p2p connection,
Ethernet VLAN p2p, p2mp, rmp, mp2mp "connections" (G.8010: ETH flow domain
fragment, MEF: Ethernet Virtual Connection), MPLS-TP MS-PW p2p and p2mp
connections, MPLS-TP LSP p2p and p2mp connections, etc.

Those "transport entities" may have one input port ("single source"), or
multiple input ports ("multiple sources") and may have one output port
("single destination"), or multiple output ports ("multiple destinations").
For the case of multiple output ports there is in principle an "internal
routing choice" within the transport entity. Whether this internal routing
choice is used depends on the customer requirement.

Those "transport entities" may carry traffic with one priority ("single
QoS"), or may carry traffic with multiple priorities ("multiple QoS").
Sequence ordering within a "transport entity" is preserved for traffic with
the same priority. Sequence ordering may not be preserved for traffic with
different priorities.
Example: an ATM VP p2p connection with three priorities will not preserve
the sequence order of cells with different priorities.

If we would follow your definition of connection, then: 
- an ATM VP p2p connection with three priorities would have been managed as
three different ATM VP p2p connections, each with a single priority... I
assume that you agree that ATM does not manage each priority as a separate
connection... Instead the p2p VP is managed as one connection.
- an Ethernet VLAN mp2mp transport entity with 10 input and 10 output ports
and two priorities would have been managed as 180 different p2p connections,
each with a single priority... I assume that you agree that Ethernet does
not manage each input port/output port/priority relation within a VLAN as a
separate connection... Instead the 10-port VLAN is managed as one transport
entity, and this 10-port VLAN can viewed as a "10-port connection" (MEF:
10-port Ethernet Virtual Connection).

Your "connection" definition is only useful from an academic interest; it is
highly confusing from a network management and operation interest as it does
not identify managed transport entities (it only identifies unmanaged flows
within such transport entities).

> Further, the OAM required for co mode network connections is NOT the
> same as the OAM required for cl-ps mode networks.

As your definition of "connection" is not aligned with the definition of
"transport entity" and OAM is used to monitor the "transport entity", your
OAM considerations are using the wrong starting point...

The n-port (n>=2) "transport entity" provides the "constraining construct
(to both traffic and OAM PDUs)". Within such n-port "transport entity"
pro-active monitoring OAM has been defined to detect the integrity of the
transport entity (i.e. are all intended input ports and output ports still
connected, are there no unintended input ports connected) and pro-active
alarm suppression OAM has been defined to distinguish between loss of input
port(s) detection due to link faults and non-link faults.

Example: Ethernet VLAN OAM is defined to operate within the scope of the
n-port VLAN transport entity, to check the integrity of this n-port VLAN
transport entity and to suppress loss of continuity alarms when those are
due to a fault of an Ethernet Link used by the n-port VLAN. 
NOTE - Ethernet VLAN OAM is **not** defined to check the integrity of the
MAC flows inside this n-port VLAN transport entity (i.e. to check your
"connections").

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: maandag 15 december 2008 11:28
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Requirement for data integrity

Thanks Sasha,

I do understand your concerns.  I suspect it's simply a matter that the
person who wrote 'integrity' was using it in some very general catch-all
sense.  But you are right that we should try and be a little more precise as
to what exactly is required.....so here is my view based on the work we have
been doing on G.800 (unified modelling).

However, I am going to copy-in Andy Reid so that he can check what I am
saying for accuracy and correct any mistakes/omissions I make....I am sure
there is a more optimal wording than I have used below, but I hope this
helps for now:

Client/server transparency means that each/every bit of the client signal is
treated equally by the server...and in particular the server MUST NOT try
and infer meaning from the client symbols, and for sure MUST NOT attempt to
change any of the client symbols.

A connection is key topological construct that has some important properties
(BTW - these properties are not simply of academic interest but have a
direct bearing on the design/operational complexity costs of running
networks):
-	A connection MUST only have a single source...so only p2p and
p2mp constructs can be called connections.
-	A connection MUST preserve the sequence ordering of client
symbols....a subtle corollary of this observation is that a connection can
only have a single QoS classification.
-	There MUST be no internal routing choice within a connection, ie
all symbols that enter a connection should appear on all the connection
egress points (with sequence ordering preserved).

Aside=> Of course the above can be compromised by network impairments.
But we can remove traffic load as a source of impairments...which is a key
consequence/requirement of a transport network using connections....and to
be very clear here:
-	it is NOT sufficient to simply provide reachability isolation
between different clients in a transport network client/server relationship,
we also need to provide performance isolation, ie the traffic behaviour of
client X cannot impact the performance experienced by client Y.
-	A (server layer) connection is a *necessary* requirement to meet
this.  For *full-sufficiency* however the server layer resources should also
not be overbooked 

I would also like to observe that the OAM required to detect/handle defects
is quite independent of the above properties of a connection....it is the
above properties (and not OAM) that confers the required 'integrity' of the
information transfer.  Further, the OAM required for co mode network
connections is NOT the same as the OAM required for cl-ps mode networks.
Example to prove why:  A connection under defect-free operation is a
constraining construct (to both traffic and OAM PDUs).  However, if there is
a misconnectivity defect present the connection may no longer be operating
as a constraining construct and traffic can leak *unidirectionally* out of a
connection *with no return path*.  What this means is that OAM of a
request/response nature cannot be relied on in such cases, ie one cannot
trace-out the leaking traffic as the OAM request PDUs can leave the
connection (at the point of leaking) but will never return.  However, in a
cl-ps mode network request/response OAM is the correct type of OAM to use.

regards, Neil

> 	Another key characteristic of transport networks is the capability
to 
> maintain
> 	Server layer OAM is used to monitor the transport integrity of the 
> client layer or client aggregate <end quote>
> 
> 3. In the requirement for mechanisms that ensure integrity of the 
> transported customer's service traffic (quoted in Adrian's original 
> mail).
> 
> I do not feel that these statements (especially one about the server 
> layer OAM) primarily mean "binary transparency".
> IMHO and FWIW an explicit requirement of the client transparency AND 
> en explicit clarification of the notion of integrity (e.g., following 
> your guidelines) would be most helpful.
> 
> My 2c,
> 	Sasha
> 
> 
> 
> 
> 
> 
>