Subject: [PWE3] FW: CESoPSN (RFC 5086): CE Signaling

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 19 Nov 2008 23:47:06 +0200

Yaakov,
I think these questions are mainly to you.

Regards,
	Sasha

> -----Original Message-----
> From: Javi [mailto:[email-masked]] 
> Sent: Wednesday, November 19, 2008 6:45 PM
> To: Alexander Vainshtein
> Cc: [email-masked]
> Subject: Re: [PWE3] CESoPSN (RFC 5086): CE Signaling
> 
> Alexander and all,
> > The CE signaling is for all timeslots carried.
> > Since these usually belong to a single trunk, 
> > this is your answer. Nothing prohibits putting a TDM 
> cross-connect (FCD)
> > before the interworking, thus mixing timeslots from 
> different physical trunks.
> > However, there is a single logical trunk from the PW point of view.
> >   
> For TDMoIP AAL.2 (RFC 5087), I understand that PW must be 
> aware of that. 
> At least, RFC5287 contents that the interface parameter "TDMoIP AAL2 
> Options" includes the field "CID mapping bases" and:
> 
> "When it is present, and the channels belong to N physical interfaces 
> (i.e., N E1s or T1s), it MUST be N
>    bytes in length.  Each byte represents a number to be 
> subtracted from
>    the CID /*to get the timeslot number for each physical 
> interface*/.  For
>    example, if the CID mapping bases parameter consists of 
> the bytes 20
>    and 60, this signifies that timeslot 1 of trunk 1 
> corresponds to CID
>    21, and timeslot 1 of trunk 2 is called 61."
> 
> But this field is not used in other methods (SAToP, TDMoIP 
> AAL.1, CESoPSN).
> 
> If a TDM cross-connect, before the interworking, is used, 
> timeslots from 
> different physical trunks are mixed.
> Then, the CE-bound instance of the CESoPSN IWF receives the 
> PW PDUs from 
> the PSN and extracts the TDM data.
> But tf in CESoPSN "there is a single logical trunk from the 
> PW point of 
> view", how to get the timeslot number for each physical interface?
> 
> Regards,
> 
> Javi
> 
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 20 Nov 2008 00:45:09 +0200

> For TDMoIP AAL.2 (RFC 5087), I understand that PW must be aware of that.
> (i.e., N E1s or T1s), it MUST be N bytes in length.  
> Each byte represents a number to be subtracted  from
> the CID /*to get the timeslot number for each physical interface*/.  
> For example, if the CID mapping bases parameter consists of the bytes 20
> and 60, this signifies that timeslot 1 of trunk 1 corresponds to CID 21, 
> and timeslot 1 of trunk 2 is called 61."

Yes, since the AAL2 method is specifically loop emulation and not circuit emulation.

By definition, curcuit emulation emulates a single circuit (aka trunk).

Y(J)S

---

From: Javi <[email-masked]>
Date: Thu, 20 Nov 2008 01:32:30 +0100

> By definition, curcuit emulation emulates a single circuit (aka trunk).
I agree, if timeslots from different physical trunks are mixed, there is 
a single logical trunk from the PW point of view.
However, how may PE egress rebuild original trunks?. (by management or 
manually)

Javi

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 20 Nov 2008 15:21:47 +0200

> However, how may PE egress rebuild original trunks?. (by management or manually)

The way it is done is by mapping the CID to the output.

This can be configured 
(e.g.  CIDs 51 through 55 are TSs 1 through 5 of the first trunk, 
CIDs 61 through 67 are TSs 1 through 7 of the second trunk, ...)
or signalled by the TLV in the control protocol extensions.
Even in the latter case you still need to know what the "first" trunk is.

Y(J)S

---

From: Javi <[email-masked]>
Date: Thu, 20 Nov 2008 17:47:52 +0100

> Even in the latter case you still need to know what the "first" trunk is.
CIDs only exists in AAL.2. My question is:
If in CESoPSN timeslots from different physical trunks are mixed
(with a TDM cross-connect before the interworking),
may PE egress insert each timeslot to its original trunk,
so that TDM trunks are emulated end-to-end CE?
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 20 Nov 2008 21:24:52 +0200

Javi,
I think that there are two different questions:

Q1: Can a single CESoPSN instance successfully carry DS0 originating on 
      multiple  trunks?
A1: Yes, it can using an appropriate NSP (DS0 cross-connect). Each endpoint
       shall maintain its own local 1:1 mapping between customer-facing DS0s
       (i.e., pairs {trunk #,  DS0 # on this trunk} and relative position of this DS0
       in each frame forming the basic CESoPSN packet payload (see Fig. 3
       in RFC 5086). RFC 5287 guarantees that the number of timeslots is the
       same for both endpoints; but actual mappings are local to each endpoint.
       This method can be extended to carry CAS in the signaling packets,
       because the same mapping would be applicable to mapping DS0 state
       to its relative position in the payload of the signaling packet. 

Q2: Can a single CESoPSN instance successfully emulate multiple TDM trunks?
A2: This depends on what you mean by "trunk emulation". IMO and FWIW, the 
       minimal requirement for successful trunk emulation would be correct propagation
       of forward and backward defect indications (AIS and RDI). A single CESoPSN
       instance can achieve that for a single E1 or T1 trunk (see Note 1 in Section 6.2),
       but not for multiple trunks.

Hopefully these notes address your concerns.

Regards,
	Sasha

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Javi
> Sent: Thursday, November 20, 2008 6:48 PM
> To: Yaakov Stein
> Cc: [email-masked]

---

From: Javi <[email-masked]>
Date: Thu, 27 Nov 2008 18:54:21 +0100

Alexander,

I have been thinking your answer and it's much more clear now.

Many thanks,

Javi

Alexander Vainshtein escribió:
>>>> However, how may PE egress rebuild original trunks?. (by 
>>>>         
>> management or manually)
>>     
>>>>     
>>>>         
>>> Even in the latter case you still need to know what the 
>>>       
>> "first" trunk is.
>>     
>>> Y(J)S
>>>
>>>   
>>>

---

From: Javi <[email-masked]>
Date: Thu, 27 Nov 2008 19:45:27 +0100

CESoPSN indicates the next ones about TDMPW Packet Format:

a) Chapter "4.2.  PSN and Multiplexing Layer Headers":

    + CESoPSN implementations working with IPv4 PSN MUST set the "Don't
    + Fragment" flag in IP headers of the packets they generate.

    Why is IP fragmentation not allowed?

b) Chapter "4.1.  CESoPSN Packet Format":

    b.1) For PSN UDP/IP, "RTP must be placed immediately after the UDP 
header,
            then CW is after RTP (UDP/RTP/CW)": I agree

    +   1.  Compliance with the existing header compression mechanisms for
    +       IPv4/IPv6 PSNs with UDP demultiplexing requires placing the RTP
    +       header immediately after the UDP header.

    b.2) For PSN L2TPv3/IP or MPLS, "CW must be placed immediately after 
the PW
       label, then RTP is after CW (PW Label/CW/RTP)": I don't 
understand why the indicated
       reasons are enough.

    +   2.  Compliance with the common PWE3 mechanisms for keeping PWs Equal
    +       Cost Multipath (ECMP)-safe for the MPLS PSN by providing for PW-
    +       IP packet discrimination (see [RFC3985], Section 5.4.3).  This
    +       requires placing the PWE3 control word immediately after the PW
    +       label.

    + 3.  Commonality of the CESoPSN packet formats for MPLS networks and
    +       IPv4/IPv6 networks with Layer 2 Tunneling Protocol Version 3
    +       (L2TPv3) demultiplexing facilitates smooth stitching of L2TPv3-
    +       based and MPLS-based segments of CESoPSN PWs (see [PWE3-MS]).

c) Chapter "4.3.  CESoPSN Control Word": it indicates:

    + LEN (bits (10 to 15) MAY be used to carry the length of the CESoPSN
    +  packet (defined as the size of the CESoPSN header + the payload size)
    +  if it is less than 64 bytes, and MUST be set to zero otherwise.
    + Note:  If fixed RTP header is used in the encapsulation, it is
    + considered part of the CESoPSN header.

    Then, it stablishes that if "CESoPSN header + the payload size" < 64 
bytes, then LEN=0.
    ITU-T Y.1453 adds that the reason of this is the next:

    + When an IP packet is transported over Ethernet, a minimum packet 
size of 64 octets is required.
    + This may require padding to be applied to the interworking packet 
payload in order to reach this
    + minimum packet size. The padding size can be determined from the 
length field so that the padding
    + can be extracted at the egress.

    But I don't agree:

    - IEEE Std 802.3-2005 indicates that "ethernet data field" must be 
 >= 46 bytes, and the minimum size
      of the Ethernet frame (without flags) must be >= 64 bytes (and <= 
1500 bytes).
    - If link level is Ethernet, the "ethernet datad field" contains the 
IP datagram, so the size of the IP datagram
       must be >= 46 bytes.
    - IP datagram contains IP header, PW Label (UDP, L2TPv3 or MPLS), 
RTP header, CW and payload.

    So, I understand that Ethernet requires that "IP, PW Label, RTP, CW" 
headers + Payload >= 46 bytes.
    If it is not so (that size is less than 46 bytes), padding would be 
necessary (and the LEN field its used
    to get the size of this padding).

    However, RFC 5086 defines "length of the CESoPSN packet" as "CESoPSN 
header + the payload size", which
    means: "RTP header + CW header + payload" and, I don't know PW 
Label?. But, in any case, IP header (20 bytes
    at least) is not included.

    In summury, I think LEN field must be zero if "IP, PW Label, RTP, 
CW" headers + Payload >= 46 bytes" or, if IP header
    is 20 bytes, when "CESoPSN packet including PW Label (PW Label, RTP, 
CW and Payload" >= 26 bytes.

Regards,

Javi

---

From: Javi <[email-masked]>
Date: Thu, 27 Nov 2008 20:11:15 +0100

I have found different references about TDM trunks must be transported 
by each TDMPW:

+ RFC 4197 (Requirements for Edge-to-Edge Emulation of TDM Circuits over 
PSN), chapter 5: indicates
   "E1, T1, E3, T3" and "NxDS0 with or without CAS" for PDH, 
"VC-11/VC-12/VC-2/VC-3/VC-4, VC-4-4c,
      VC-4-16c, VC-4-64c" for SDH.

+ RFC 4553 (SAToP): indicates T1, E1, T3, E3 trunks.

+ RFC 5086 (CESoPSN): only indicates "E1" and "T1" (ESF and SF) trunks

+ RFC 5087 (TDMoIP AAL1, AAL2): indicates "E1, T1, E3, T3"  (and 
fractional E1, fractional T1).

+ ITU-T Y.1453 (with packet format aligned with RFC 5086 for PSN 
UDP/IP), chapter 7.1:
    - unstructured TDM: E1, DS1 (T1), DS2, E3, DS3, Nx64 and 
"Synchronous serial data" (V.36 and V.37).
    - structured TDM: E1 (and fractional E1), DS1 (and fractional DS1), 
DS2 and "Multiple synchronous DS0s".

So, I think they are not consistent among themselves:

1) DS2 is only indicated by ITU-T Y.1453.

2) SDH is only indicated by RFC 4197.

3) RFC 5087 indicate E1/T1 and E3/T3, but RFC 5086 only E1/T1.

4) In that context, what means exactly "NxDS0"?

5) And "Multiple synchronous DS0s"?

6) And "Synchronous serial data"?

I think it would be necessary to clarify the TDM trunks may be supported 
by each TDMPW (apart from
fractional or no, and "NxDS0 Services" or no).

Regards,

Javi

---

From: Javi <[email-masked]>
Date: Thu, 27 Nov 2008 20:31:35 +0100

ITU-T 1.453, Appendix IV, indicates:

+ Using eight or more PDUs per packet invalidates the use of the AAL 1 
sequence number
+ mechanism, and hence complicates interworking with ATM-based CES systems.

That is not mentioned by RFC 5087:

+ Why does it not appear on RFC 5087?

+ Why is "AAL 1 sequence number mechanism" invalidated if there are 8 or 
more SAR-PDUs
  per TDMPW packet?. The NS field in SAR-PDU header is 3 bits, but I 
don't understand the resason,
  and even less when ITU-T Y.1453 (and RFC 5087) suggests between 5 and 
15 PDUs per packet for
  E3 and DS3 circuits.

Regards,

Javi

---

From: Javi <[email-masked]>
Date: Thu, 27 Nov 2008 20:38:52 +0100

ITU-T Y.1453 (chapter 7.1) indicates that the architecture TDMoIP must 
support
the unstructured TDM type:

    + 5) N × 64 k (i.e., for N = 1 as defined in ITU-T Rec. I.231.1 
[17], for N = 2 as defined in
    +   ITU-T Rec. I.231.5 [37], for N = 3 as defined in ITU-T Rec. 
I.231.10 [38] and for
    +   N = 6 as defined in ITU-T Rec. I.231.6 [39]);

If it is unstrutured, it would only be supported by SAToP (RFC 4553), 
not CESoPSN neither TDMoIP AALx.

However, I think "RDSI Circuit-mode bearer services" differentiates 
channels DS0 (B and D) and, so,
it would be structured TDM type. In that case, CESoPSN and TDMoIP 
AAL1/AAL2 would be able
to transport that services.

Regards,

Javi

---

From: Javi <[email-masked]>
Date: Thu, 27 Nov 2008 21:03:06 +0100

Two questions:

I) RFC 5087, chapter 3.6 (TDMoIP AAL2 Options), establishes:

    + CID mapping bases is an OPTIONAL parameter; its existence and length
    +   are determined by the length field.  If the mapping of AAL2 CID
    +   values to a physical interface and time slot is statically
    +   configured, or if AAL2 switching [Q.2630.1] is employed, this
    +   parameter MUST NOT appear.

About that:

a) If mapping of AAL2 CID values to a physical interface and time slot 
is statically configured:
  a.1) may it only be manually or by management?, or is it possible by 
signalling?
  a.2) If signalling is possible, what would Sub-TLV (MPLS, RFC5287) or AVPs
        (L2TPv3, draft-ietf-l2tpext-tdm-06) be used?

b.1) Is it possible to employ AAL2 switching [Q.2630.1] over a TDMoIP AAL.2?
b.2) Where is Q.2630.1 signalling transported?
b.3) In which node is switching done? (each TDMPW is defined between two 
PEs, without other PW nodes among them)

II) RFC 5087, Chapter 10 (Applicability Statement) establishes:

    + Data in inactive channels is not transported in AAL2 mode, and thus
    + this data will differ from that of the native service.

    What does it means?. As far as I know, ATM AAL.2 (ITU-T Y.363.2) 
doesn't transport
    either inactive channels, then the same as AAL2 TDMoIP TDMPWs.

Regards,

Javi

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 1 Dec 2008 09:05:52 +0200

Javi

There were long discussions on the issue of the length field.

You are missing an essential point by considering only the IP case.

Consider what happens when the TDM PW is over MPLS.
Then you don't know precisely the size of the headers,
since you don't know if there are 0, 1, 2, ... tunnel headers.

So you are right - the proper action would be to look at the length of entire Ethernet payload,
but this length is in general unknown to the IWF in charge of the PW processing. 
Only the length of payload + CW + PW label is known.

It was decided to err on the safe side.
Furthermore, since the PW processor wil in general not know what transport layer will be used
(MPLS, IP, pure layer 2 Ethernet, other), this same strategy was used in the IP case as well.

Y(J)S

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Javi [[email-masked]]
Sent: Thursday, November 27, 2008 8:45 PM
To: [email-masked]
Subject: [PWE3] RFC 5086: TDMPW Packet format

    But I don't agree:

Regards,

Javi