RFC 4717, "Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks", December 2006

Errata ID: 2917
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-10-17
Held for Document Update by: Stewart Bryant
Date Held: 2011-08-05

(2)  Section 5.1.2 -- misleading specification due to omission.

On top of page 9, Section 5.1.2 says:

   The next 4 bits provide space for carrying protocol-specific flags.
   These are defined in the protocol-specific details below.
|
|  The next 6 bits provide a length field, which is used as follows:
   [...]

'The next 6 bits' is misleading; as indicated in the (unnumbered)
figure at the bottom of page 8, there is a 2-bit 'Res' field between
the Flags field and the Length field; unfortunately, the text lacks
any description of that field.
To fill this gap, the above text should be amended to say:

   The next 4 bits provide space for carrying protocol-specific flags.
   These are defined in the protocol-specific details below.

|  The subsequent 2-bit Res field is reserved; it SHOULD be set to 0
|  by the sending PE and ignored by the receiving PE.
|
|  The next 6 bits provide a length field, which is used as follows:
   [...]

Note: 'SHOULD' is appropriate as future (optional) specifications
      might assign semantics to that field.


(3)  Section 5.4 -- word omission

Section 5.4 (on page 10 of RFC 4717) says:

   The setting of the TTL value in the PW label is application
|  dependent.  In any case, [RFC3032] TTL processing procedure,
   including handling of expired TTLs, MUST be followed.

It should say:

   The setting of the TTL value in the PW label is application
|  dependent.  In any case, the [RFC3032] TTL processing procedure,
   including handling of expired TTLs, MUST be followed.


(4)  Section 6.3 -- word omission

On page 14, Section 6.3 of RFC 4717 contains the numbered item:

|      -iv. The Length of AAL5 frame may exceed the MTU of the PSN.
            This requires fragmentation, which may not be available to
            all nodes at the PW endpoint.

The RFC should say:

|      -iv. The Length of an AAL5 frame may exceed the MTU of the PSN.
            This requires fragmentation, which may not be available to
            all nodes at the PW endpoint.


(5)  Section 7.4 -- distorting typo

The initial text of Section 7.4 (on page 17 of RFC 4717) contains
the line:

|    - (b) On the ATM side of the PW
                                  ^^
This is misleading.  It certainly should say:

|    - (b) On the ATM side of the PE
                                  ^^

(6)  Section 8 -- misleading short text / lack of precision

Section 8 of RFC 4717 (on page 18) says:

   The N-to-one mode (N >= 1) described in this document allows a
   service provider to offer an ATM PVC- or SVC-based service across a
   network.  The encapsulation allows multiple ATM VCCs or VPCs to be
   carried within a single PSN tunnel.  A service provider may also use
   N-to-one mode to provision either one VCC or one VPC on a tunnel.
   This section defines the VCC and VPC cell relay services over a PSN
   and their applicability.

For clarity and added precision, it should say:

   The N-to-one mode (N >= 1) described in this document allows a
   service provider to offer an ATM PVC- or SVC-based service across a
|  packet switched network.  The encapsulation allows multiple ATM VCCs
   or VPCs to be carried within a single PSN tunnel.  A service provider
   may also use N-to-one mode to provision either one VCC or one VPC on
   a tunnel.  This section defines the VCC and VPC cell relay services
   over a PSN and their applicability.


(7)  Section 8.1 -- various clarifications


(7b)  inprecise wording not reflecting requirements language elsewhere

In Section 8.1, the 3rd paragraph below Figure 4 (on mid-page 19)
says:

|  As shown above, in Figure 4, the ATM Control Word is inserted before
|  the ATM service payload.  It may contain a length field and a
   sequence number field in addition to certain control bits needed to
   carry the service.

Taken literally, this text is misleading and partially contradicts
the requirements specified in Section 5.1 (in the second paragraph
on page 7).  In particular, the entire ATM control word (the 3rd word
in Figure 4) is optional, and *not* the various bit fields therein.
To properly reflect these requirements, the RFC should says instead:

|  As shown above, in Figure 4, the optional ATM Control Word (if
|  present) is inserted before the ATM service payload. It contains a
   length field and a sequence number field in addition to certain
   control bits needed to carry the service.

(7c)  bad grammar

Within Section 8.1, the last paragraph on page 20 says:

     * When multiple VCCs or VPCs are transported in one pseudowire,
       VPI/VCI values MUST be unique.  When the multiple VCCs or VPCs
|      are from different a physical transmission path, it may be
                         ^^^                          ^
       necessary to assign unique VPI/VCI values to the ATM connections.
       If they are from the same physical transmission path, the VPI/VCI
       values are unique.

It should say:

     * When multiple VCCs or VPCs are transported in one pseudowire,
       VPI/VCI values MUST be unique.  When the multiple VCCs or VPCs
|      are from different physical transmission paths, it may be
                         ^                          ^^
       necessary to assign unique VPI/VCI values to the ATM connections.
       If they are from the same physical transmission path, the VPI/VCI
       values are unique.



(8)  Sections 9.3 ff. -- alignment flaws in artwork

(8a)
Within Section 9.3, the top part of Figure 8 on page 24 contains
a misaligned border;

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               PSN Transport Header (As Required)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |                      Pseudowire Header                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | [...]

should be:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               PSN Transport Header (As Required)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |                      Pseudowire Header                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | [...]

The same flaw recurs ...

(8b)  within Section 9.4.1, in Figure 9 on page 25;
(8c)  within Section 9.4.1, in Figure 10 on page 26;
(8d)  within Section 11.1, in Figure 12 on page 29;


(9)  Section 9.4.1 -- word omission

On mid-page 25, the bullet,

     * VCI Bits

|      The 16-bit Virtual Circuit Identifier (VCI) incorporates ATM
       Layer VCI value of the cell.

should say:

     * VCI Bits

|      The 16-bit Virtual Circuit Identifier (VCI) incorporates the ATM
       Layer VCI value of the cell.


(10)  Section 10.1 -- multiple mis-specifications

(10a)
As will be explained below, the initial part of Section 10.1
(on page 27) comprises several issues.

The RFC says:

|  The AAL5 CPCS-SDU is prepended by the following header:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |  Res  |T|E|C|U|Res|  Length   |   Sequence Number (Optional)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              "                                |
   |                     ATM cell or AAL5 CPCS-SDU                 |
   |                              "                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 11: AAL5 CPCS-SDU Encapsulation

It should say:

|  The AAL5 CPCS-SDU or OAM cell is prepended the ATM Control Word:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  |0 0 0 0|T|E|C|U|Res|  Length   |     Sequence Number (or 0)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|    Figure 11: Control Word used with AAL5 CPCS-SDU Encapsulation

Rationale:

(a.1)
The text is wrong and misleading; the figure does not (merely) show
'the prepended header' (i.e., the "ATM Control Word", according to
other parts of this RFC), but the payload as well!
The top level structure of the encapsulation is specified in Figure 4;
hence, it suffices to specify the details of the Control Word here.
Accordingly, the above replacement omits the payload and presents
a modified figure caption.

(a.2)
The 4 most significant bits of the ATM Control Word MUST be all zero.
Denoting the field as 'reserved' is misleading; future specifications
MUST NOT change the value.  See Section 5.1.2 of this RFC, RFC 4385,
and the recently published RFC 4928 for additional explanation!

(a.3)
The 'Sequence Number' field is *not* optional in the control word,
as erroneously might be deduced from the original version of the
figure; it MUST always be present; according to Section 5.1.2, only
the *processing* of this field is optional, and the reserved value 0
is *not* a valid sequence number; it indicates non-use of sequence
number processing.  Hence, the lower half of the ATM Control Word
either contains a sequence number or 0.


(10c)  incomplete specification

The description of the fields in Figure 11 is incomplete.
As a service to the reader, for completeness the following
text should be added at the end of Section 10.1:

|  For a description of the Length and Sequence Number fields, see
|  Section 5.1.2.


(11)  Section 11.1 -- surprising/confusing specification details

(11b)  lack of precision

Below Figure 12, the RFC text on page 29 says:

   The M, V, Res, and C bits are as defined earlier for VCC One-to-one
   cell mode.

For clarity and completeness, it should say:

   The M, V, Res, and C bits are as defined earlier for VCC One-to-one
|  cell mode.  M must be set to 1 and V must be set to 0 for AAL5 PDU
|  Encapsulation; further details regarding the C bit are given below.




(13)  Section 11.2.2 -- significant typo (wrong bit field name)

Section 11.2.2 (on page 31) contains the bullet:

      -iii. The least significant bit for the last ATM cell in the PSN
|           frame is set to the value of the UU bit of Figure 12.
                                             ^^
It should say:

      -iii. The least significant bit for the last ATM cell in the PSN
|           frame is set to the value of the U bit of Figure 12.
                                             ^


(15)  Abuse of language

'AAL5' stands for "ATM Adaptation Layer 5".  Hence, the wording
"ATM AAL5" is a replication considered a rough abuse of language.

All occurrences of "ATM AAL5" in the RFC should be corrected to "AAL5".

Notes:

This is sections 2, 3, 4, 5, 6, 7b, 7c, 8, 9, 10(a), 10(a1), 10(a2), 10(a3), 10(c), 11(b), 13, and 15 of errata 999

Report New Errata