Subject: [PWE3] draft-ietf-pwe3-cesopsn-05.txt

From: Stewart Bryant <[email-masked]>
Date: Fri, 04 Nov 2005 14:41:33 +0000

I was taking a final look at  draft-ietf-pwe3-cesopsn-05.txt
to see if it was ready to send to the IESG, and had a
number of comments that I think need a look at first.

- Stewart

----------------

ABSTRACT

This document describes a method for encapsulating structured (NxDS0)
TDM signals as pseudo-wires over packet-switching networks (PSN). In
this regard, it complements similar work for structure-agnostic
emulation of TDM bit-streams [PWE3-SAToP].

SB - Will probably have a problem with abreviations in the Abstract
      (and in the Introduction)

============

1. Introduction

This document describes a method for structure-aware encapsulation
structured of NxDS0 TDM signals as pseudo-wires over packet-switching
networks (PSN). In this regard, it complements similar work for for
structure-agnostic emulation of TDM bit-streams [PWE3-SAToP].

Ability to emulate NxDS0 circuits provides for saving PSN bandwidth,

SB - The ability to emulate?

supports DS0-level grooming and distributed cross-connect applications.
It also enhances resilience of CE devices to effects of loss of packets
in the PSN.

===========

1. For the synchronous approach - dedicated pins that allow
     extraction/insertion of the relevant constant-rate bit-streams into
     appropriate positions in the E1 or T1 trunk
2. For the signaling approach:
     a) Dedicated memory-mapped registers which allow reading the actual
        stabilized CAS bits values and writing the desired combination
        of CAS bits values to be inserted into the resulting E1 or T1
        trunk
     b) Generation of interrupts when a de-bounced change of CAS bits
        has been detected.

Note: Another method of exchanging signals between telephony
applications is called Common Channel Signaling (CCS). This method is
not considered in this document in detail.

SB - Not sure that the above hardware considerations belong
in this protocol definition.

=========

2. Fixed end-to-end delay: CESoPSN implementations SHOULD provide the
     same end-to-end delay between any given pair of PEs regardless of
     the bit-rate of the emulated service.

SB - I don't think that this says what you mean :) The delay BETWEEN
    the PEs depends on the PSN (and will vary). I think that you mean
    that AC-AC delay will be constant for any given PE pair.

=========

4. IANA Considerations

Allocation of PW Types for the corresponding CESoPSN PWs is defined in
[PWE3-IANA].

SB - A very strange place to put IANA considerations. By convention
      it is placed towards the end on the draft.

=========

5. CESoPSN Encapsulation Layer
    5.1. CESoPSN Packet Format

The CESoPSN header MUST contain the CESoPSN Control Word (4 bytes) and
MAY also contain a fixed RTP header [RFC3550]. If the RTP header is
included in the CESoPSN header, it MUST immediately follow the CESoPSN
control word in all cases except UDP demultiplexing, where it
MUST precede it (see Fig. 1a, Fig. 1b and Fig. 1c below).

Note: Such an arrangement complies with the traditional usage of RTP
for the IPv4/IPv6 PSN with UDP demultiplexing while making CESoPSN PWs
ECMP-safe for the MPLS PSN by providing for PW-IP packet
discrimination(see [PWE3-ARCH], Section 5.4.3) and facilitating smooth
stitching of L2TPv3-based and MPLS-based segments of CESoPSN PWs (see
[PWE3-MS]).

SB - I know what you are saying, but it's not very clear
      to a first time reader. Would be good to look at the
      above and re-state more clearly.

=============

  Usage of MPLS and L2TPv3 as demultiplexing layers is explained in
[PWE3-ARCH] and [L2TPv3] respectively.

SB - Is that true - what about signalling?

UDP as the multiplexing mechanism for PWs SHOULD be used with manual
SB - When using UDP as the .......
SB - Also I think that you need to revisit the above because -
      at the moment we only have a manual method (a MUST)

configuration of both source and destination UDP ports.

===============

M - a 2-bit modifier field. In case of L cleared allows
     discrimination of signaling packets, carrying RDI of the
     attachment circuit across the PSN etc. In case of L set
     only the '00' value is currently defined, other values are
     reserved for future extensions. L and M bits can be
     treated as a 3-bit code point space that is described in
     detail in Table 1 below

SB - Do you need to define the mapping of the M bits in the
      table below to the CW - presumable it's big-endian?

==============

The FRG bits in the CESoPSN control word MUST be cleared for all
services excluding trunk-specific NxDS0 with CAS. In case of these
services they MAY be used to denote fragmentation of the multiframe
structures between CESoPSN packets as described in [PWE3-FRAG], see
also below.

SB - Where below - have I missed something?

===============

Sequence number is used to provide the common PW sequencing function as
well as detection of lost packets. It MUST be generated in accordance
with the rules defined in [RFC3550], Section 5 for the RTP sequence
number.

SB - do you mean 5.4 in this document or RFC3550 - section 5?

SB - also given that RFC3550 does not actually same conventional
      wrap through zero - it might be as well to say so here
      so there is no ambiguity WRT the packet/cell drafts.

      The same fix should be applied to SATOP.

=============

1. The amount of TDM data in a CESoPSN packet MUST be either an
     integer multiple of the basic structure size

SB - either needs an or in the sentence.

=============

Signaling packets SHOULD be carried a separate dedicated PW. However,

SB - carried in a

=============

implementations MAY carry them in the same PW as the TDM data packets
for the basic NxDS0 service. The methods of "pairing" the PWs carrying
TDM data and signaling packets for the same extended NxDS0 service are
our of scope of this document.

SB - how does the association happen when they are carried
      in seperate PWs?

============

2. If RTP header is used in the data packets, it MUST be also used in

SB - If an RTP header

==============

    7.2. IWF operation

SB - Looking at all the TDM drafts I notice that we
      have used this term quite a lot (including
      interestingly RFC-4197), but we have not defined it
      anywhere. I think that we should include a definition
      here (and TDMoIP if needed) and also put one
      in SATOP when we fix up the IESG review comments.

==============

The CE-bound CESoPSN IWF SHOULD use the sequence number in the control
word for detection of lost and mis-ordered packets. If the RTP header
is used, the RTP sequence numbers MAY be used for the same purposes.

SB - is SHOULD a strong enough condition for sequence
      numbers - given the serious consequences of pkt
      loss or misorder?

===============

Notes:

1. If the pair of IWFs at the two ends of the PW have been configured
     to force the TDM trunks carrying their ACs to transmit AIS upon
     reception of data packets with the L bit set and to transmit RAI
     upon reception of data packets with the R bit set or with the L bit
     cleared and M bits set to '10', this PW provides a BW-saving

SB - BW?
=================

Malformed packets are detected by mismatch between the expected packet
size (taking the value of the L bit into account) and the actual packet
size inferred from the PSN and multiplexing layers. When RTP is used,
lack of correspondence between the PT value and that allocated for this
direction of the PW MAY also be used for this purpose. Malformed in-
order packets MUST be discarded by the CE-bound IWF and replacement
data generated as for lost packets.

SB - surely this is just one type of malformation i.e. truncation
      this sort of open a door to the question but then fails to
      answer it.

==================

10. Security Considerations

This document does not affect the underlying security issues of
specific PSN.

In addition, it defines misconnection detection capabilities of
CESoPSN. These capabilities increase resilience of CESoPSN to
misconfiguration and some types of DoS attacks.

SB - My view is that this security section needs to be
      improved before it is will get accepted. For instance
      there is no reference to the reduced security of the
      emulated service compared to a traditional service.
      However I guess we will find out from the SATOP review
      what we need to do with TDM security.

===================

11. Applicability Statement

CESoPSN is an encapsulation layer intended for carrying circuits NxDS0
services with or without CAS over PSN.

CESoPSN allows, within reasonable limits, to emulate end-to-end delay

SB - you need to define "reasonable"

===================

CESoPSN allows the PSN bandwidth conservation by carrying only AIS
and/or Idle Code indications instead of data.

CESoPSN allows deployment of BW-saving Fractional point-to-point E1/T1

SB - definition of BW?

===================

Being a constant bit rate (CBR) service, CESoPSN cannot provide TCP-
friendly behavior under network congestion. If the service encounters
congestion, it should be temporarily shut down.

SB - s/should/SHOULD/

==========

Faithfulness of a CESoPSN PW may be increased if the carrying PSN is
Diffserv-enabled and implements a PDB that guarantees low loss and low
jitter.
SB - PDB?

===========

CESoPSN does not provide any mechanisms for protection against PSN
outages. As a consequence, resilience of the emulated service to such
outages is defined by the PSN behavior. On the other hand:

o  The jitter buffer and packets' reordering mechanisms
     associated with CESoPSN increase resilience of the emulated
     service to fast PSN rerouting events

SB - do you mean fast reroute in the accepted sence. Maybe
      we need to say a bit more about re-convergence.

==========

14. INFORMATIVE REFERENCES

SB - since there need to be another pass you should use RFC
      style reference where possible - it saves the reader
      using the ref section when it is an RFC.

=============

ANNEX B. REFERENCE PE ARCHITECTURE FOR EMULATION OF NXDS0 SERVICES

Structured TDM services do not exist as physical circuits. They are
always carried within appropriate physical attachment circuits (AC),
and the PE providing their emulation always includes a Native
Processing Block (NSP) commonly referred to as Framer. As a

SB - Native Service Processing Block (NSP)?

==============

Notes: This model is asymmetric:
      o  AC state indication can be forwarded from the framer
          to multiple instances of the CESoPSN IWF

SB - use of IWF (and below) - term not really defined and has
      diffrent meanings in ITU and IETF.
      looking back you use this term a lot Do we want to
      find a new name - or define it isn such a way that the
      IETF understands what you mean?

==============

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3