ITU
- Telecommunication Standardization Sector Temporary Document 2066/Rev.1
Geneva, 29 January - 2 February 2001
Question(s): 7/7
SOURCE: RAPPORTEUR
TITLE: DRAFT
REVISED ITU-T RECOMMENDATION X.85/Y.1321: "IP OVER SDH USING LAPS"
____________________
Summary
This Recommendation provides a simple HDLC specification named LAPS to adapt IP directly to SDH. The Service Access Point Identifier (SAPI) is introduced to encapsulate IPv6, IPv4, PPP and other upper layer protocols. The LAPS is fully compatible with RFC 2615 when the Address field is set to “11111111” and the data link is set to operate as the way RFC 2615 defines.
CONTENTS
Recommendation
Q.921 (03/93)
Page
Introduction.............................................................................................................................................. 3
1 Scope............................................................................................................................................. 4
2 References..................................................................................................................................... 5
......... 2.1 Normative
references.................................................................................................................... 5
......... 2.2 Informative
references................................................................................................................... 5
3 Definitions...................................................................................................................................... 6
4 Abbreviations.................................................................................................................................. 6
5 The
protocol framework of IP over SDH using LAPS....................................................................... 7
6 Physical
layer and its primitives........................................................................................................ 9
7 Service
facilities and protocol specifications of Data link.................................................................... 11
7.1 UITS and its
specification......................................................................................................... 11
Annex
A The LAPS specification........................................................................................................... 13
A.1 General............................................................................................................................... 13
A.2 Frame
structure for peer-to-peer communication................................................................... 13
A.3 Elements
of procedures and formats of fields for data link layer.............................................. 17
A.4 Definition
of the peer-to-peer procedures of the data link layer............................................... 18
Annex
B Primitives between layer 3
or other upper protocols and data link, layer 1 and data link................. 20
B.1 General............................................................................................................................... 20
B.2 Layer
3 - data link layer primitives........................................................................................ 20
B.3 Layer
1 - data link layer primitives........................................................................................ 20
B.4 The
connection management entity - Data link layer primitive.......................................................... 20
B.5 Parameter
definition............................................................................................................. 20
B.6 Primitive
relationship description........................................................................................... 20
Annex
C The self-synchronous
scrambling/descrambling (x43 + 1) function description.............................. 22
Appendix
I The main differences between LAPS and PPP/HDLC............................................................ 24
Introduction
Currently IPv4 is transported largely over telecommunications facilities or channels to support IP protocols and to provide IP-related applications. One of the best channels is SDH. SDH and related WDM (Wavelength Division Multiplex) optical transport network are considered to be the foundation for the physical layer of the broadband IP and B-ISDN. SDH had been deployed all over the world in recent years.
How to fully make use of these existing huge broadband resources effectively to provide Internet data communication services? How to combine IP-based network with SDH to establish the lower cost and high-speed based protocol model? This Recommendation provides LAPS (a type of HDLC) to adapt directly IP to SDH. The model of IP directly over SDH is particularly well suited for existing IPv4 and forthcoming IPv6 Internet engineering applications.
DRFT REVISED Recommendation X.85/Y.1321
IP over SDH using LAPS
1 Scope
This Recommendation:
• builds
the simple HDLC protocol model of the IP over SDH in the light of ITU-T
Recommendation X.200;
• specifies
multiple logical links specified by the Service Access Point Identifier (SAPI)
to encapsulate IPv6-based, IPv4-based, PPP and other upper protocol packets;
and
• defines
the various physical interfaces and primitives to be used in the "IP over
SDH using LAPS" network.
The relationship between LAPS and IP and SDH physical layer, along with relative primitives are presented as the following diagram (see Figure 1).
FIGURE 1/X.85/Y.1321
The
relationship between LAPS and IP, LAPS and SDH
This Recommendation does not specify the mapping LAPS to SDH, and also does not specify any LAN accessing to "IP over SDH using LAPS" network. No change is made for all IP-based protocols (including RFC 791 and RFC 2460 ) and all SDH standards.
IP over SDH using LAPS can be extended, in future amendments, to support additional new types of Internet service. LAPS is not used to coexist with HDLC (ISO 3309 or RFC 1662), LAPB/ITU‑T X.25 and LAPD/ITU-T Q.921 within the same physical layer in future, and is limited within the area of this IP over SDH using LAPS.
2 References
The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; all users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of currently valid ITU-T Recommendations is regularly published.
2.1 Normative references
2.1.1 Identical Recommendations | International Standards
[1] ITU-T Recommendation X.200 (1994) | ISO/IEC 7498-1 (1994), Information technology - Open Systems Interconnection - Basic reference model: The basic model.
[2] ITU-T Recommendation X.211 (1995) | ISO/IEC 10022 (1996), Information technology - Open Systems Interconnection - Physical service definition.
[3] ITU-T Recommendation X.212 (1995) | ISO/IEC 8886 (1996), Information technology - Open Systems Interconnection - Data link service definition.
2.1.2 Others
[4] ITU-T Recommendation G.703 (1998), Physical/electrical characteristics of hierarchical digital interfaces.
[5] ITU-T Recommendation G.707 (1996), Network node interface for the Synchronous Digital Hierarchy (SDH).
[6] ITU-T Recommendation G.708 (1999), Sub-STM-0 network node interface for the Synchronous Digital Hierarchy (SDH).
[7] ITU-T Recommendation G.957 (1995), Optical interfaces for equipments and systems relating to the synchronous digital hierarchy.
[8] RFC 791 (1981), Internet Protocol - DARPA Internet Program - Protocol Specification.
[9] RFC 2460 (1998), Internet Protocol, Version 6 (IPv6 -) Specification.
[10] RFC 2615 (1999), PPP over SONET/SDH.
NOTE - The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
2.2 Informative references
[11] ITU-T Recommendation Q.921 (1997), Physical/electrical ISDN user-network interface - Data link layer specification.
[12] ITU-T Recommendation X.25 (1996), Interface between Data Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit.
[13] ISO/IEC 3309 (1991), Information technology - Telecommunications and information exchange between Systems - High-level Data Link Control (HDLC) procedures - Frame structure.
[14] RFC 1662 (1994), PPP in HDLC-like Framing.
3 Definitions
For the purposes of this Recommendation, the following definitions apply:
3.1 IP over SDH: The data communication architecture of combination Internet protocols with SDH network. The physical, data link and network layer or other protocols are defined as SDH, LAPS, and IP-based protocols or PPP protocols.
3.2 LAPS: A type of HDLC, including data link service and protocol specification which are used to the network of IP over SDH.
3.3 UI frame: UI frame is a frame which is used to transfer Layer 3 User data or user data of other protocols, including IPv4‑based packet (refer to RFC 791), IPv6-based packet (refer to RFC 2460) or PPP frames etc in the way of unacknowledged information transferring.
4 Abbreviations
This Recommendation uses the following abbreviations:
CRC Cyclic
redundancy check
DS Differentiated
Services
FCS Frame
check sequence
HDLC High
level data link control
ICMP Internet
control message protocol
IP
over SDH Internet
protocol over SDH
IPv4 Internet
protocol (version 4)
IPv6 Internet
protocol (version 6)
LAN Local
area network
LAPB Link
access procedure - Balanced
LAPS Link
access procedure - SDH
LLC Logical
link control
MAC Media
access control
MRU Maximum
receive unit
PPP Point-to-point
protocol
RFC Request
for comment
SAP Service
access point
SAPI Service
access point identifier
SDH Synchronous
digital hierarchy
SDU Service
data unit
sSTM Sub-STM
STM Synchronous
transfer module
TCP Transmission
control protocol
UDP User
datagram protocol
UI Unnumbered
information (frame, transferring Layer 3 User data)
UITS Unacknowledged
information transfer service
VC Virtual
container
5 The protocol framework of IP over SDH using LAPS
IP over SDH using LAPS is a type of data communication architecture of combination Internet protocol or other protocols with SDH network. The physical, link and network layer or other protocols are specified as SDH, LAPS and IPv4/IPv6 or PPP etc respectively as the layer/protocol stack for IP over STM-N shown in Figure 2 and the layer/protocol stack for IP over sSTM-n in Figure 3. The Figure 4 and Figure 5 illustrate protocol configuration and network examples respectively.
FIGURE 2/X.85/Y.1321
Layer/Protocol
Stack for IP over STM-N using LAPS
FIGURE 3/X.85/Y.1321
Layer/Protocol Stack for IP over sSTM using LAPS
FIGURE 4/X.85/Y.1321
The Protocol Configuration of IP over SDH using LAPS
FIGURE 5/X.85/Y.1321
"IP over SDH using LAPS" network example
6 Physical layer and its primitives
This Recommendation treats SDH transports as octet-oriented synchronous point-to-point links. The SDH frames are an octet-oriented synchronous multiplex mapping structure that specifies a series of standard rates, formats and mapping methods. Table 1 shows the bandwidth value of the VCs and Table 2 of the STMs that are currently specified. The use of control signals is not required. The self-synchronous scrambling/descrambling (x43+ 1) function is applied during insertion/extraction into/from the synchronous payload envelope (see Annex C). This Recommendation uses the future concatenation of virtual containers as defined in the new version of ITU-T Recommendation G.707.
TABLE 1/X.85/Y.1321
The bandwidth of the VCs
|
VC type |
VC bandwidth (kbit/s) |
VC payload (kbit/s) |
|
VC-11 |
1 664 |
1 600 |
|
VC-12 |
2 240 |
2 176 |
|
VC-2 |
6 848 |
6 784 |
|
VC-3 |
48 960 |
48 384 |
|
VC-4 |
150 336 |
149 760 |
|
VC-4-4c |
601 344 |
599 040 |
|
VC-4-16c |
2 405 376 |
2 396 160 |
|
VC-4-64c* |
9 621 504 |
9 584 640 |
|
* For further study. |
||
TABLE 2/X.85/Y.1321
STM interface rates
|
STM type |
STM bit rate (kbit/s) |
|
sSTM-11 |
2 880 |
|
sSTM-12 |
5 184 |
|
sSTM-14 |
9 792 |
|
sSTM-18 |
19 792 |
|
sSTM-116 |
37 444 |
|
sSTM-21 |
7 488 |
|
sSTM-22 |
14 400 |
|
sSTM-24 |
28 224 |
|
STM-0 |
51 840 |
|
STM-1 |
155 052 |
|
STM-4 |
622 080 |
|
STM-16 |
2 488 320 |
|
STM-64 |
9 953 280 |
Communication service facilities between data link layer and physical layer are accomplished by means of primitives (see Table 3) according to the principle of ITU-T Recommendation X.211. Primitives specification of Table 3 specifies the interaction between data link layer and physical layer to invoke and provide a service, and presents the elements.
TABLE 3/X.85/Y.1321
The
primitives of physical layer
|
Primitive name |
Primitive type |
|
PH-DATA |
Request Indication |
7 Service facilities and protocol specifications of data link
The data link protocol is LAPS, which provides point-to-point transferring over SDH virtual containers and interface rates. The supported UITS is connection-less-mode service.
Communications between data link and network layer or the associated upper protocols is accomplished by means of primitives (see Table 4) according to the principle of ITU-T Recommendation X.212.
TABLE 4/X.85/Y.1321
The primitives of LAPS (NOTE 1)
|
Primitive name |
Primitive type (parameter) |
|
DL-UNACK-DATA |
Request (User data, DS codepoint) Indication (User data) |
|
NOTE 1 - The basic functions of primitives are presented in Annex B. |
|
7.1 UITS
and its specification
UITS shall follow the octet-synchronous procedures and rules for unacknowledged information transfer specified in Annex A. The related protocol elements are specified in Table 5.
The service facility of UITS provided to layer 3 or other upper protocols via SAP is the DL-UNACK- DATA request primitive with "User data" (IP packet) and "DS codepoint" parameters, and the DL-UNACK-DATA indication primitive with the "User data" (IP packet). "User data" is the outgoing/incoming IP packet including IP header and payload without any modification. The second parameter is the "6‑bits DS codepoint". This parameter shall be used to perform some link functions between IPv4/IPV6 and LAPS or between IPv4/IPv6 and PPP to provide the support of the differentiated services; it shall not be used into any frame of LAPS.
TABLE 5/X.85/Y.1321
UITS specification
|
a) |
UI frames shall always be commands. |
|
b) |
Service Access Point Identifier (SAPI) value (decimal): 0057 for IPv6, 0021 for IPv4. When the PPP is used to be encapsulated via SAPI for the compatibility with RFC 2615, it is noted: (1)Both FCS-32 and FCS-16 can be set by provisioning and is not negotiated. The 32-bit FCS must be used for all SDH rates. For STM-1c/VC-4 only, the 16-bit FCS may be used, although the 32-bit FCS is recommended. (2)Regarding the path signal label (C2) of SDH, for compatibility with RFC 2615, the signal label value of (x43 + 1) scrambling is changed from 24 (18 hex) to 22 (16 hex). Additionally, the LAPS does also provide the signal label value 207 (CF hex) to indicate PPP without scrambling. (3)The data link will be operated as RFC 2615 defines and the Address field is set to “11111111”, the padding field followed information field and the functions of Link Control Protocol and Network Control Protocol will be included. |
|
c) |
The default maximum frame size shall be capable of supporting an information field of 1 600 octets (at least) for both IPv4-based and IPv6-based applications. |
|
d) |
Poll/Final bit shall always be set to "0". |
ANNEX A
The LAPS specification
A.1 General
This Annex specifies the frame structure, elements of procedure, format of fields and procedures for the octet-synchronous operation of the LAPS.
A.2 Frame structure for peer-to-peer communication
A.2.1 General
All data link layer peer-to-peer exchanges are in frames conforming to the format shown in Figure A.1.
A.2.2 Flag
sequence
All frames start and end with the flag sequence consisting of one 0 bit followed by six contiguous 1 bits and one 0 bit. The flag preceding the address field is defined as the opening flag. The flag following the Frame Check Sequence (FCS) field is defined as the closing flag. The closing flag also serves as the opening flag of the next frame, in some applications. However, all receivers shall be able to accommodate receipt of one or more consecutive flags. The Flag Sequence shall be transmitted during inter-frame time fill.
A.2.3 Address
field
The address field shall consist of a single octet as illustrated in Figure A.1 and its value is 0x04 (hexadecimal).
A.2.4 Control
and SAPI field
The control field shall consist of a single octet which contains the binary sequence 0x03 (hexadecimal), the Unnumbered Information (UI) command with the Poll/Final (P/F) bit set to zero. The use of other Control values is reserved. Figure A.1 illustrates the frame formats, with a control field of a single octet. For the SAPI field, please refer to A.3.2.
A.2.5 Information
field
The information field of a frame, when present, follows the SAPI field and precedes the frame check sequence. The contents of the information field shall consist of an integer number of octets.
A.2.6 Transparency
An octet stuffing procedure is applied. Each frame begins and ends with the flag 0x7E. A transmitting data link layer entity shall examine the frame content between the opening and closing flag sequences (address, control, SAPI, information and FCS fields) during transmission; if the flag sequence occurs anywhere within the information field of the frame, it shall be converted to the sequence 0x7D 0x5E. Occurrence of 0x7D is transformed to 0x7D 0x5D also. At the receiver, the stuff patterns are removed and replaced with the original fields.
A.2.7 Frame Check Sequence
(FCS) field
The FCS field shall be a 32-bit sequence. It shall be the ones complement of the sum (modulo 2) of:
– the remainder of xm (x31 + x30 + ... + x + 1) divided (modulo 2) by the generating polynomial, where m is the number of bits of the information over which the CRC is calculated; and
– the remainder of the division (modulo 2) by the generating polynomial of the product of x32 by the information over which the CRC is calculated. The 32-bit FCS generating polynomial is:
G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1
The result of the CRC calculation is placed with the least significant bit right justified in the FCS field. As a typical implementation at the transmitter, the initial content of the register of the device computing the remainder of the division is preset to all "1"s and is then modified by division by the generating polynomial (as described above) on the address, control, SAPI and information fields over which the CRC is to be calculated; the ones complement of the resulting remainder is put into the 32-bit FCS field.
As a typical implementation at the receiver, the initial content of the register of the device computing the remainder of the division is preset to all "1"s. The final remainder, after multiplication by x32 and then division (modulo 2) by the generating polynomial of the serial incoming protected bits and FCS, shall be (in the absence of errors):
C(x) = x31 + x30 + x26 + x25 + x24 + x18 + x15 + x14 + x12 + x11 + x10 + x8 + x6 + x5 + x4 + x3 + x + 1
The
computation of 32-bit FCS and 16-bit FCS is referred to RFC 2615 for
compatibility with RFC 2615. In this case of 16-bit FCS, the length of FCS is
changed to the two octets in Figure A.1 and Figure A.4.
FIGURE A.1/X.85/Y.1321
Frame
format
A.2.8 Format convention
A.2.8.1 Numbering convention
The basic convention used in this Annex is illustrated in Figure A.2. The bits are grouped into octets. The bits of an octet are shown horizontally and are numbered from 1 to 8. Multiple octets are shown vertically and are numbered from 1 to N.
A.2.8.2 Order of bit transmission
The octets are transmitted in ascending numerical order; inside an octet bit 8 is the first bit to be transmitted.
A.2.8.3 Field mapping convention
When a field is contained within a single octet, the lowest bit number of the field represents the lowest order value.
When a field spans more than one octet, the order of bit values within each octet progressively decreases as the octet number increases. The lowest bit number associated with the field represents the lowest order value.
For example, a bit number can be identified as a couple (o, b) where o is the octet number and b is the relative bit number within the octet. Figure A.3 illustrates a field that spans from bit (1, 3) to bit (2, 7). The high order bit of the field is mapped on bit (1, 3) and the low order bit is mapped on bit (2, 7).
An exception to the preceding field mapping convention is the data link layer FCS field, which spans four octets. In this case, bit 1 of the first octet is the low order bit and bit 8 of the 4th octet is the high order bit (see Figure A.4), please refer to RFC 2615.
FIGURE A.2/X.85/Y.1321
Format
convention
FIGURE A.3/X.85/Y.1321
Field mapping convention
FIGURE A.4/X.85/Y.1321
32-bit FCS mapping format
A.2.9 Invalid frames
An invalid frame is a frame which:
a) is
not properly bounded by two flags; or
b) has
fewer than six octets between flags of frames; or
c) contains
a frame check sequence error; or
d) contains
a service access point identifier (see A.3.3) which is mismatched or not
supported by the receiver; or
e) contains
an unrecognized Control field value; or
Invalid frames shall be discarded without notification to the sender. No action is taken as the result of that frame.
A.3 Elements of procedures and formats of fields for data link layer
A.3.1 General
The elements of procedures define the command that is used on the data link connections carried on the SDH virtual containers and interface rates.
Procedures are derived from these elements of procedures and are described in clause A.4.
A.3.2 Address field and data link SAPI
The SAPI field format is shown in Figure A.5. The binary sequence of two bytes is assigned to data link layer Service Access Point Identifier (SAPI).
FIGURE A.5/X.85/Y.1321
SAPI field format
A.3.3 Service
access point identifier (SAPI)
The SAPI identifies a point at which data link layer services are provided by a data link layer entity to a layer 3 (e.g. IP or ICMP) or other upper protocols. Consequently, the SAPI specifies a data link layer entity type that processes a data link layer frame and also a layer 3 entity or other upper protocol entity that is to receive information carried by the data link layer frame. The SAPI bit order is shown in Figure A.5 and its values are listed in the TABLE A.2.
TABLE A.2/X.85/Y.1321
SAPI values
|
SAPI value |
Related layer 3 |
|
0021 |
IPv4-based service. |
|
0057 |
IPv6-based service. |
|
other |
Reserved for future extension. |
A.4 Definition of the peer-to-peer procedures of the data link layer
The procedure for use by the data link layer is specified as unacknowledged information transfer.
A.4.1 Transmission of unacknowledged information
SDUs (Service Data Unit) to be conveyed by means of unacknowledged information transfer are passed to the data link layer by layer 3 or other upper protocols using DL-UNACK-DATA request. The SDUs passed by layer 3 or other upper protocols shall be transmitted in a UI frame.
NOTE - The term "transmission of a UI frame" refers to the delivery of a UI frame by the data link layer to the physical layer.
A.4.2 Receipt of unacknowledged information
On receipt of a UI frame with a SAPI which is supported by the receiver, the contents of the information field shall be passed to the layer 3 or other upper protocols using the data link primitive DL-UNACK-DATA indication. Otherwise, the UI frame shall be discarded.
A.4.3 Procedure on the Connection management entity
The connection management entity is used optionally to monitor the link status of receiving the peer link frame. It is local matter only and has not any associated frame to be used between the two sides.
--After initialization (the defaults of T200 and N200 are set to 1 seconds and 3 respectively), the link entity enter the normal way of transmitter and receiver.
--If the timer T200 expires before any frame (including information frame and inter-frame time fill) is received, the link entity shall restart timer T200 and decrement the retransmission counter N200.
--If the timer T200 expires and retransmission counter N200 has been decremented to zero before any frame is received, the link entity shall indicate this to the local connection management entity by means of the MDL-ERROR indication primitive, and restart timer T200 and recover the value of N200.
--The value of T200 and N200 shall be configurable. The minimum unit configured of T200 and N200 is 100 milliseconds and 1 respectively.
ANNEX B
Primitives between layer 3 or other upper protocols and link layer, layer 1 and link layer
B.1 General
Communications between layers for this Recommendation are accomplished by means of primitives. Primitives represent, in an abstract way, the logical exchange of information and control between the data link and layer 3 or other upper protocols. They do not specify or constrain implementations.
B.2 Layer 3 or other upper protocol entity- Data link layer primitives
The DL-UNACK-DATA (Request and Indication) primitives are used to request and indicate layer 3 IP packets (User data) or user data of the other upper protocols which are to be transmitted, or have been received, by the data link layer entity using the UITS.
B.3 Layer 1 - Data link layer primitives
B.3.1 PH-DATA
The PH-DATA primitives are used to request and indicate data link frames used for data link layer peer-to-peer communications passed to and from the physical layer.
B.4 The connection management entity - Data link layer primitive
B.4.1 MDL-ERROR
The MDL-ERROR primitives are used to indicate the connection management entity that an error has occurred as a result of communication with the data link layer peer entity. The actions to be taken by the connection management entity on receipt of an MDL-ERROR indication primitive.
B.5 Parameter definition
The parameter is associated with a primitive and contains information related to the service. In the case of the DATA primitives, the parameter data contains the Service Data Unit that allows the service user to transmit its Protocol data Unit to the peer service user entity. For example, the DL‑UNACK-DATA parameter contains layer 3 information. The PH-DATA parameter contains the data link layer frame. This Recommendation specifies two parameters: User data and 6-bits DS codepoint for differentiated services.
B.6 Primitive relationship description
Primitive procedures specify the interactions between adjacent layers to invoke and provide a service. The service primitives represent the elements of the procedures. Figure B.1 presents Primitives Relationship between layer 3 and layer 2, layer 2 and layer 1.
SDH Physical Layer
FIGURE
B.1/X.85/Y.1321
Primitives Relationship
ANNEX C
The self-synchronous scrambling/descrambling (x43+ 1) function description
C.1 The self-synchronous (x43 + 1) scrambler/descrambler
The operation diagram of (x43 + 1) self-synchronous scrambler transmitter and receiver (see Figure C.1 and Figure C.2) are as follows. XOR is an exclusive-OR gate function. The output bits is exclusive-ored with the raw input data bit to produce the transmitted bits. The order of bit transmission within an octet is the most significant bit first. The purpose of performing scrambling/descrambling function is to protect correct operation of SDH. The performing scrambler and descrambler shall be required for higher order VC-n. The C2 byte coding of the high order path signal label is specified (see ITU-T Recommendation G.707) to indicate the contents of synchronous payload envelope. It is recommended that "24" (18 hex) is used to indicate LAPS with (x43 + 1) scrambling. When the LAPS is set to be compatible with RFC2615, the value of the SDH path signal label is required to change from 24 (18 hex) to 22 (16 hex). Additionally, the LAPS shall also provide the signal label value 207 (CF hex) to indicate PPP without scrambling The V5 byte coding of the lower order path signal label is currently not yet defined (see ITU-T Recommendation G.707). Scrambling shall be not required for lower order VC‑2, VC-12 and VC-11.
EDITOR'S NOTE - The V5 coding above is to be determined. It is needed to make further liaison statement with ITU-T SG 15.
FIGURE C.1/X.85/Y.1321
Transmitter diagram
FIGURE C.2/X.85/Y.1321
Receiver diagram
Appendix I
The main differences between LAPS and PPP/HDLC
Appendix I represents the main differences between LAPS and PPP/HDLC (see Table I.1).
TABLE I.1/X.85/Y.1321
Comparison of LAPS in ITU-T
Recommendation X.85/Y.1321 with
PPP/HDLC (RFC 1662) in IETF
|
|
LAPS |
PPP/HDLC |
|
Multiprotocol encapsulation |
Using a set of SAPIs |
Using PPP |
|
Flag of HDLC frame |
0x7e |
0x7e |
|
Address field of HDLC frame |
A single octet length. The all-station address is 0xff that will be used to be compatible with RFC 2615, the LAPS station addresses is assigned to 0x04. Frame with unrecognized addresses shall be discarded. |
A single octet length. The all-station address is 0xff, individual station addresses are not assigned. Frame with unrecognized addresses shall be discarded. |
|
Control field of HDLC frame |
The same |
The same |
|
Protocol field 16/8 bits |
Two-octet is used as SAPI |
It has been used |
|
Padding field |
Unused |
On transmission, the information field may be padded with an arbitrary number of octets up to the Maximum Receive Unit (MRU), which defaults to 1 500 octets. By negotiation, consenting PPP implementation may use other values for the MRU. |
|
Magic number and associated configuration facilities |
Unused |
This configuration option provides a method to detect looped-back links and other link layer anomalies. |
|
Link initialization control |
Unused |
It has been used |
|
Protocol-Field-Compression |
Unused |
Unused |
|
Address-and-Control-Field-Compression |
Unused |
Unused |
|
Restart Timer |
Unused |
It is used in PPP, but it is not specified in RFC 1619 up to now. Its value depends on the link round-trip time which is changed along with the different SDH rates. This Timer is necessary for peer-to-peer communication for PPP. |
|
FCS field |
32 bits |
32/16 bits, FCS length is set by provisioning. |
|
Control escape octets |
0x7e and 0x7d |
Sending implementations must escape the Control escape octets. |
|
Invalid Frames |
Frames which are too short (less than 6 octets when using the 32-bit FCS), or which end without a control field, or in which octet-framing is violated (by transmitting a "0" stop bit where a "1" bit is expected), are silently discarded, and not counted as a FCS error. |
Frames which are too short (less than 4 octets when using the 16-bit FCS), or which end with a control escape octet followed immediately by a closing Flag sequence, or in which octet-framing is violated (by transmitting a "0" stop bit where a "1" bit is expected), are silently discarded, and not counted as a FCS error. |
|
Octet-synchronous |
Yes |
Yes |
|
inter-frame time fill |
Using Flag |
Using Flag |
|
Payload scrambling |
Scrambling is used only. The high order Path Signal Label (C2) is set to 24 (0x18H) when using x43 + 1 scrambling. The lower order Path Signal Label (V5) is set to code (101 Binary) when using x43 + 1 scrambling (it has been indicated by ITU-T SG 15). |
Both scrambling and non-scrambling are used. The Path Signal Label (C2) is set to 22 (0x16H) when using x43 + 1 scrambling. If scrambling has been configured to be off, then the value 207 (0xcf) is used. |
The frame format comparison of LAPS with RFC 1662 is given in Figure I.1.
FIGURE I.1/X.85/Y.1321
The frame format comparison of LAPS in X.85/Y.1321 with PPP/HDLC in RFC 1662
__________________