[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PWE3] draft-ietf-pwe3-cesopsn-05.txt
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
pwe3 at ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3