ITU - Telecommunication Standardization Sector Temporary Document 2031/Rev.3

STUDY GROUP 7

Geneva, 29 January – 2 February 2001

Question(s): 7/7

SOURCE: RAPPORTEUR

TITLE: RESPONSE TO COMMENTS ON X.85/Y.1321

_____________

COMMUNICATION

TO: IETF LIAISON OFFICER

APPROVAL: ITU-T Study Group 7

FOR: ACTION

DEADLINE: June 2001

CONTACT: Mr. Shaohua Yu Tel: +86 27 87 69 34 41
P. R. China Fax: +86 27 87 69 37 84
Email: shuyu@wri.com.cn

Thank you for your comments on X.85/Y.1321 . The three comments raised from IETF and associated responses from Q.7/7 (Q.10/7 in the last study period) are given below.

(1) First, we would like to reiterate a point we raised previously, but that apparently was not received in time to be considered during the March, 2000 Study Group 7 meeting. The LAPS specification identifies IPv4 packets by the two-byte sequence <04 03> at the front of the packet rather than PPP’s 4-byte sequence <ff 03 00 21>. Likewise, LAPS uses <06 03> at the front of an IPv6 packet rather than using <ff 03 00 57> as is done in PPP. In all other respects, LAPS and PPP appear to be complimentary and consistent with each other. Consequently, we believe that it is desirable to have LAPS identify higher-layer packets by the first four bytes rather than just the first two. Reusing the PPP protocol identifiers for LAPS, and hence matching PPP’s on-the-wire packet format, has the advantage that should LAPS at some later time need to define L2 signalling, LAPS could incorporate PPP signalling by reference without having to obsolete or change LAPS itself in any way (e.g., by using LAPS for some things, and PPP for others). Given that there does not appear to be a strong technical justification for choosing to de-multiplex on the first two bytes versus the first four bytes, choosing the latter would appear to be a more flexible choice. Indeed, vendors implementing both LAPS and PPP would be required to examine the first 4 bytes anyway and it would be better to have LAPS do the same so that implementors are not led to believe that identifying packets by the first two bytes is sufficient.

The change from 2-byte sequence to 4-byte sequence has been made in the amendment 1 to Recommendation X.85. So <04 03 00 21> and <04 03 00 57> indicate that Ipv4 and Ipv6 are encapsulated respectively. There should not be any confusion between the use of PPP or LAPS and LAPS SAPI because the SDH VC-4 signal label (C2 byte) had been specified for PPP or LAPS in ITU-T SG15 and make the distinction.

(2) Second, in section A.2.1 there is a NOTE which begins with the sentence “The LAPS shall be encapsulated into a 32-bit word-oriented frame as for the need of providing frame delineation, transparent transferring, and error detection.” We find this sentence confusing and difficult to understand; we suggest that it be clarified. Also, the immediately-following sentence indicates that the framing format for STM-64 needs further study. In real life there is already a de facto framing format for STM-64 rates specified in RFC 2615, and this format has multi-vendor deployment. It is identical to the format used on lower-speed SDH circuits.

“NOTE - The LAPS shall be encapsulated into a 32-bit word-oriented frame as for the need of providing frame delineation, transparent transferring, and error detection. The frame format of STM-64 or VC-4-64c needs further study” has been removed in the Amendment 1 to X.85/Y.1321.

(3) Finally, in section A.2.7 the document describes the FCS computation in terms of polynomial math, a description which can be implemented only if the bit ordering used for frame octets is clearly specified. The document should make it explicitly clear that the bit ordering of the frame used for computation is little-end-first, since for SDH the bit order used for the FCS computation differs from the transmission bit order (a “feature” which is utterly unique to the PPP over SONET specification). We also suggest that the description of the field mapping of the FCS into the packet, in section A.2.8.3, be made explicitly clear in the same context since the bit which is “bit 1 of the first octet” in the FCS is ambiguously related to the bit ordering that the computation was performed in.

To be completely compatible with RFC 2615 in FCS bit order, the FCS octet sequence has been modified as RFC 2615 defined.

Attachments: TD 2045/Rev.3 on draft Amendment 1 to Recommendation X.85/Y.1321 (2000), and TD 2066/Rev.1, draft revised Recommendation X.86/Y.1321 (comprising the above Amendment 1)

____________________