PWE3 Working Group A. Vainshtein - Editor (Axerra Networks) Y. Stein - Editor (RAD Communications) Internet Draft I. Sasson (Axerra Networks) A. Sadovski (Axerra Networks) Expiration Date: E. Metz (Thrupoint) March 2003 T. Frost (Zarlink Semiconductor) P. Pate (Overture Networks) October 2002 Unstructured TDM Circuit Emulation Service over Packet Switched Network (UCESoPSN) draft-vainshtein-pwe3-ucesopsn-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes a method for encapsulating unstructured TDM digital signals as pseudo-wires (PWs) over various packet-switched networks (PSN). In this regard it complements similar work for SONET/SDH circuits. TABLE OF CONTENTS 1. Introduction......................................................2 2. Terminology and Reference Models..................................3 2.1. Terminology...................................................3 2.2. Reference Models..............................................3 2.2.1. Generic Models............................................3 2.2.2. Synchronization Considerations and Deployment Scenarios...4 2.2.3. Service Examples..........................................4 3. Scope.............................................................4 3.1. Emulated Services.............................................4 3.2. Protocol Layers...............................................5 3.3. CE Signaling..................................................5 Vainshtein et al. [Page 1] TDM Circuit Emulation Service over PSN October 2002 4. UCESoPSN Encapsulation............................................5 4.1. Basic Packet Format...........................................5 4.2. CESoPSN Header................................................6 4.2.1. The RTP Header............................................6 4.2.2. UCESoPSN Control Word.....................................7 4.2.3. RTP Header Suppression....................................8 4.3. Payload Data Format...........................................9 4.3.1. Common Considerations.....................................9 4.3.2. Octet-aligned Payload Format for Unstructured T1 Circuits 10 5. UCESoPSN Operation...............................................11 5.1. Payload Parameters...........................................12 5.1.1. PW Type..................................................12 5.2. Encapsulation Layer Parameters...............................12 5.2.1. The RTP Header Suppression Indicator.....................12 5.2.2. Payload Bytes............................................12 5.2.3. RTP-related Parameters...................................12 5.3. End Service Inactivity Behavior..............................13 5.4. Description of the IWF operation.............................13 5.4.1. PSN-bound Direction......................................13 5.4.2. CE-bound Direction.......................................14 5.5. UCESoPSN Defects.............................................15 5.5.1. Misconnection............................................15 5.5.2. Re-Ordering and Loss of Packets..........................15 5.5.3. Malformed Packets........................................16 5.5.4. Loss of Synchronization..................................16 5.6. Performance Monitoring.......................................17 5.6.1. Errored Data Blocks......................................17 5.6.2. Errored, Severely Errored and Unavailable Seconds........17 5.7. QoS Issues...................................................17 6. RTP Payload Format Considerations................................17 6.1. Resilience to moderate loss of individual packets............17 6.2. Ability to interpret every single packet.....................17 6.3. Non-usage of the RTP Header Extensions.......................18 6.4. Compression of RTP headers...................................18 7. Congestion Control (RFC 2914) Conformance........................18 8. FFS Issues.......................................................18 9. Security Considerations..........................................19 10. Applicability Statement.........................................19 11. IANA Considerations.............................................20 12. Intellectual Property Disclaimer................................20 ANNEX A. UCESoPSN ENCAPSULATION FOR DIFFERENT TYPES OF PSN..........24 1. Introduction This document describes a method for encapsulating "low-rate" TDM circuits (E1, T1, E3, T3) as pseudo-wires (PWs) over packet-switched networks (PSN). Emulation of these circuits has been explicitly defined as one of the WG objectives in the PWE3 WG Charter. In this regard, this document complements similar work for SONET/SDH circuits (see [PWE3-SONET]). The TDM bit-streams considered in this document can be used to carry different types of traffic including voice, data, and private leased Vainshtein et al. Expires March 2003 [Page 2] TDM Circuit Emulation Service over PSN October 2002 line services. These services use different mechanisms for imposing data structures on the bit streams that are commonly referred to as framing mechanisms. The present document describes a method for encapsulating unstructured TDM bit streams for transport over packet switched networks (PSNs). It may also be used for structured TDM streams, when the framing and channelization structure are deemed inconsequential from the transport point of view. This means that: 1. The encapsulation is agnostic to any specific framing mechanism 2. It carries any possible structures imposed on the TDM bit stream transparently 3. It does not provide any mechanisms for locating framing or data structures imposed on the TDM bit streams. The solution presented in this document fits the framework for PW services as described in [PWE3-ARCH] and satisfies the general requirements put forward in [PWE3-REQ]. In its basic form it uses RTP [RFC1889] for sequencing and synchronization services. Optionally the RTP header may be suppressed. 2. Terminology and Reference Models 2.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The terms defined in [PWE3-ARCH], Section 1.4 are consistently used, usually without additional explanations. This document uses terms and acronyms that are commonly used in conjunction with the TDM services. In particular: o Alarm Indication Signal (AIS) denotes a special bit pattern in the TDM bit stream indicating the presence of an upstream circuit outage o Remote Alarm Indication (RAI) denotes a special pattern in the TDM bit stream returned by the receiver experiencing an AIS condition. 2.2. Reference Models 2.2.1. Generic Models Generic models that have been defined in Sections 4.1 (Network Reference Model), 4.3 (Maintenance Reference Model) and 4.4 (Protocol Stack Reference Model) of [PWE3-ARCH] are fully applicable for the purposes of this document without any modifications. All the services considered in this document represent special cases of the generic bit-stream payload type defined in Section 3.3.3 of [PWE3- ARCH]. Vainshtein et al. Expires March 2003 [Page 3] TDM Circuit Emulation Service over PSN October 2002 2.2.2. Synchronization Considerations and Deployment Scenarios The Network Synchronization reference model and deployment scenarios for emulation of TDM services have been described in [PWE3-TDM-REQ], Section 4.2. 2.2.3. Service Examples Fig.1 below presents several examples of a T1 Emulated Service. _/_ \ / \ / \ +------+ Physical /+-+ \ / \__/ \ _ Hub Site |Site A| T1 / |P| +---+ \ (CE-3) |T1 #1=|====================|E|=| R | +---+ +-+ \ OC12+------+ |(CE-1)| \ |1| | |===| | | |---------| | +------+ / +-+ +---+ | | | | ========|=T1 #1| / | R |=|P| | | +------+ T1 +---+ DS3 / +-+ +---+ | | |E| ========|=T1 #2| |Site B| | |-----------|P| | R |===| | |3|---------| | |T1 #2=|====| M |===========|E|=| | +---+ +-+ / +------+ |(CE-2)| | |-----------|2| +---+ / +------+ +---+ \ +-+ / \ ___ ___ / \_/ \____/ \___/ Figure 1: T1 Emulation Example Diagram In this diagram, T1 circuits are attached to the PE devices in three different ways: 1. As a physical T1 line (between CE-1 and PE-1) 2. As a virtual T1 signal multiplexed in DS3 using one of possible multiplexing formats (between CE-2 and PE-2, see [T1.103] for details). M denotes a PDH multiplexor 3. As a virtual T1 signal mapped into an appropriate SONET virtual tributary, the latter being multiplexed in OC-12 (between CE-3 and PE-3 - see [T1.105] or [G.707] for details). 3. Scope 3.1. Emulated Services This specification describes service-specific encapsulation layer for edge-to-edge emulation of the following TDM circuits over a PSN: 1. Unstructured E1 2. Unstructured T1 (DS1) 3. Unstructured E3 4. Unstructured T3 (DS3) All these services are defined in normative references [G.702,G.703] and are inherently based on an 8 kHz clock. We shall further refer to a 125 microseconds' sample of any of these services as its "native Vainshtein et al. Expires March 2003 [Page 4] TDM Circuit Emulation Service over PSN October 2002 circuit frame". However, such a sample does not have to coincide with the real framing structure imposed on the service. 3.2. Protocol Layers This specification defines the encapsulation layer for edge-to-edge emulation of TDM services mentioned in Section 4.1. In accordance with the principle of minimum intervention (see PWE3- ARCH], Section 3.3.5) the TDM payload is, whenever possible, encapsulated without any changes. 3.3. CE Signaling Certain framing mechanisms allow the CEs to insert special patterns in the bit streams that are interpreted as CE signals. Since we are emulating unstructured circuits, most such signals will be carried transparently along with the TDM payload data and will not necessitate special processing. However, some of these patterns represent changes in the state of the end service, for example indication of the end service failure. Such signals SHOULD be carried by the PW in such a way as to facilitate localization of faults. 4. UCESoPSN Encapsulation 4.1. Basic Packet Format The basic UCESoPSN packet format is shown in Fig. 2 below. Vainshtein et al. Expires March 2003 [Page 5] TDM Circuit Emulation Service over PSN October 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | PSN and multiplexing layer headers | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Fixed | +-- --+ | RTP | +-- --+ | Header (see [RFC1889]) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | UCESoPSN Control Word | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Packetized TDM data (Payload) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. Basic UCESoPSN Packet Format Note: Under certain circumstances the RTP header may be suppressed in order to conserve network bandwidth. See section 4.2.3 for details. 4.2. CESoPSN Header 4.2.1. The RTP Header In its basic format UCESoPSN uses the fields of the fixed RTP header (see [RFC1889], Section 5.1) in the following way: 1. V (version) is always set to 2 2. P (padding) is always set to 0 3. X (header extension) is always set to 0 4. CC (CSRC count) is always set to 0 5. M (marker) is set to 0 6. One PT value MUST be allocated from the range of dynamic values (see [RTP-TYPES]) for every UCESoPSN PW: a) Allocation is done during the PW setup and MUST be the same for both PW directions b) The PE at the PW ingress MUST set the PT value (or values) in the RTP header to the allocated value c) The PE at the PW egress MAY use this value (these values) to detect malformed packets 7. Sequence number is used primarily to provide the common PW sequencing function as well as detection of lost packets. It is generated and processed in accordance with the rules established in [RFC1889] 8. Timestamps are used primarily for carrying timing information over the network: a) Their values are generated in accordance with the rules established in [RFC1889] b) Frequency of the clock used for generating timestamps MUST be a integer multiple of 8 kHz Vainshtein et al. Expires March 2003 [Page 6] TDM Circuit Emulation Service over PSN October 2002 c) Possible modes of timestamp generation are discussed below 9. The SSRC (synchronization source) value in the RTP header MAY be used for detection of misconnections Note: The same PT value can be reused between different PWs. The RTP header in UCESoPSN can be used in conjunction with at least the following modes of timestamp generation: 1. Absolute mode: the ingress PE sets timestamps using the clock recovered from the incoming TDM circuit. As a consequence, the timestamps are closely correlated with the sequence numbers. This is the default mode that MUST be supported by all the PEs implementing UCESoPSN 2. Differential mode: PE devices connected by the PW have access to the same high-quality synchronization source, and this synchronization source is used for timestamp generation. As a consequence, the second derivative of the timestamp series represents the difference between the common timing source and the clock of the incoming TDM circuit. Usage of other timestamp generation modes is left for further study. Absolute mode allows operation in the Asynchronous Carrier's Carrier deployment scenario. Differential mode facilitates improvement of quality of the recovered clock in the One Synchronous Network and Synchronous Carrier's Carrier deployment scenarios defined in [PWE3- TDM-REQ]. 4.2.2. UCESoPSN Control Word The structure of the UCESoPSN Control Word is shown in Fig. 3 below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E|R|D|A|X| Reserved | Optional sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. Structure of the UCESoPSN Control Word o Bit E - if set, indicates presence of an extended control word. Extensions of the control word are not defined in this specification, hence currently this bit MUST be always set to 0 o Bit R - carries Remote Loss of Packets indication, i.e., is set in packets transmitted by PE-2 to PE-1 if PE-2 detected loss of packets in the stream received from PE-1 o Bit D - carries Local Idle Code indication. If set, represents the Idle Code state in the payload of an unstructured T3 PW end service. A packet with the D bit set MAY carry no payload Vainshtein et al. Expires March 2003 [Page 7] TDM Circuit Emulation Service over PSN October 2002 o Bit A - carries Local AIS indication. If set, represents AIS of the PW end service at ingress. A packet with the A bit set MAY carry no payload o Bit X - MAY carry indication of RAI condition of the PW end service o Reserved - SHOULD be set to 0 at ingress and SHOULD be ignored at egress o Optional sequence number - the packet sequence number that MUST either continuously cycle from 0 to 0x3fff or (if not used) be set to all zeroes at ingress. If used and RTP is not suppressed, it MUST coincide with the 14 least significant bits of the RTP sequence number. The UCESoPSN control word allows: 1. Differentiation between the intra-PSN and extra-PSN faults as causes for the emulated service outages 2. Conservation of bandwidth by inhibition of invalid data transmission (AIS, idle code) 3. PW egress-to-ingress signaling of intra-PSN problems 4. Implementation of the common PW sequencing function if the RTP header is suppressed (see Section 4.2.3). Notes: 1. AIS condition for E1, T1 and E3 services can be detected without a framer in the PE 2. An appropriate framer must be used in the PE device in order to detect RAI condition for all services. If this condition cannot be detected, bit X MUST be set to 0 at the PW ingress 3. A T3 framer must be used in the PE device in order to detect AIS and Idle Code conditions of a T3 service. If these conditions cannot be detected, bits A and D MUST be set to 0 at the PW ingress 4. The structure of the UCESoPSN control word is aligned with that defined in [PWE3-SONET] 5. Either A or D bit (but not both) can be set in the UCESoPSN control word. 4.2.3. RTP Header Suppression The RTP header in Fig. 1 MAY be suppressed if the both PEs support such suppression. In this case the sequence number in the UCESoPSN control word MUST be used and MUST be generated in accordance with rules stated in [RFC1889]. The resulting structure of the UCESoPSN packet is shown in Fig. 4 below. Vainshtein et al. Expires March 2003 [Page 8] TDM Circuit Emulation Service over PSN October 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | PSN and multiplexing layer headers | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | UCESoPSN Control Word with mandatory sequence number | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Packetized TDM data (Payload) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4. UCESoPSN Packet Format with Suppressed RTP Header Note: In the text below "basic UCESoPSN format" consistently refers to the packet format described in Fig. 2 as opposed to format described in Fig. 4. 4.3. Payload Data Format 4.3.1. Common Considerations Payload of a single UCESoPSN packet SHOULD contain one or more native circuit frames of the carried service (or, in other terms, the time in microseconds required for filling a single UCESoPSN packet with the TDM data SHOULD be an integer multiple of 125). For example, when transporting an E1 circuit the payload length SHOULD be a multiple of 32 bytes. Keeping an integer multiple of native circuit frames per packet facilitates: o Emulation of performance monitoring parameters of "classic" carriers of TDM circuits (e.g., SONET/SDH) o Deployment of application-specific local handling of packet loss that prevents early detection of the AIS defect by certain types of CEs. However, since UCESoPSN is used for carrying unstructured circuits, there is no special meaning to the first, last or any other specific bit in the packet with regard to framing. In addition to the "native circuit frame" mode, the packet payload size MAY be an integer multiple of 47, without regard to the native circuit frame. This basic length facilitates interworking with existing AAL1- based circuit emulation services [I.363.1]. The size (in bits) of native circuit frame for all the circuits considered in this document excluding T1 is a multiple of eight, and hence the UCESoPSN packet containing an integer multiple of native circuit frames is octet-aligned. The T1 frame size of 193 bits is not a multiple of eight. UCESoPSN supports the following solutions for this problem: Vainshtein et al. Expires March 2003 [Page 9] TDM Circuit Emulation Service over PSN October 2002 1. Use padding to align each native circuit frame to 25 octets. This option is discussed in Section 4.4.2 below 2. Use packet payload size that contains integer multiples of 47 bytes rather than integer multiples of a native circuit frame 3. Use packet payload size that is an integer multiple of 193 bytes. For a specific PW implementing UCESoPSN, the payload size MUST be: 1. Defined during the PW setup and remain fixed for the duration of the PW existence. Such an arrangement: a) Ensures that the UCESoPSN packets are transmitted at (approximately) constant rate b) Facilitates replacement of lost packets with predefined amount of data 2. Selected in such a way that the size of the containing UCESoPSN packet does not exceed the path MTU between the PE devices terminating the PE. Subject to this limitation the PSN operator may select the actual payload size for a specific PW taking into account the following considerations: 1. Packetization latency constraints vs. the PSN bandwidth and switching capacity utilization 2. Limitations imposed by implementations in the terminating PEs UCESoPSN uses the so-called "Telecom" bit ordering, i.e., each payload octet is: o Filled by consecutive bits coming from the PWES from most to least significant bit o Played out into the PWES in the same order. 4.3.2. Octet-aligned Payload Format for Unstructured T1 Circuits [G.802] defines mapping of an unstructured E1 circuit into a structured E1 one. This mapping is used to define an octet-aligned payload format (shown in Fig. 5 below) for carrying unstructured T1 over a PSN. Vainshtein et al. Expires March 2003 [Page 10] TDM Circuit Emulation Service over PSN October 2002 "Timeslots" | 1 | ... | 24 | 25 | |0 1 2 3 4 5 6 7| ... |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| ------------+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ N C F 1|D D D D D D D D| ... |D D D D D D D D|D| padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ a i r 2|D D D D D D D D| ... |D D D D D D D D|D| padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t r a ...|D D D D D D D D| ... |D D D D D D D D|D| padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i c m ...|D D D D D D D D| ... |D D D D D D D D|D| padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v u e ...|D D D D D D D D| ... |D D D D D D D D|D| padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e i s ...|D D D D D D D D| ... |D D D D D D D D|D| padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t M|D D D D D D D D| ... |D D D D D D D D|D| padding | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Figure 5. The Octet-Aligned T1 Payload Format Note: Each row in the matrix presented in Fig. 4 contains exactly 193 payload data bits and 7 padding bits. However, no explicit alignment of the rows with the T1 frames is implied. 5. UCESoPSN Operation Note: This section includes some implementation considerations. These considerations represent non-normative information and will be moved to an appropriate Appendix in the next update. Edge-to-edge service emulation of a TDM service using UCESoPSN assumes the following elements: o Two PW end services of the same type o Packetizer at the PW ingress o Jitter buffer and de-packetizer at the PW egress. Setup of a UCESoPSN PW assumes exchange of the following information: o Types of end services. In order to be connected by a UCESoPSN PW, these types MUST be the same and define the PW type. PW types supported by UCESoPSN MUST be accommodated into the common enumeration of PW types o Encapsulation layer-specific parameters that define specific instantiation of the protocol. This document defines only how the values of these parameters should be encoded. The actual signaling protocols for exchanging these parameters between the PE peers ("PE/PW signaling" in terms of [PWE3-ARCH]) are out of scope of this document. Description of the UCESoPSN-based edge-to-edge service emulation includes the following elements: o Definition of the end service inactive state behavior towards the CE Vainshtein et al. Expires March 2003 [Page 11] TDM Circuit Emulation Service over PSN October 2002 o Description of the IWF operation in CE-bound and PSN-bound direction. Details are presented below. 5.1. Payload Parameters 5.1.1. PW Type PW types (a.k.a. VC types) have been defined in [PWE3-CONTROL]. PW types used for UCESoPSN PW are assigned in such a way as to avoid overlap with types assigned in other PWE3 documents. The following PW types are defined in this document for UCESoPSN-based PWs: o E1 - 66 o T1 - 67 o Octet-aligned T1 - 69 o E3 - 70 o T3 - 71 5.2. Encapsulation Layer Parameters 5.2.1. The RTP Header Suppression Indicator The RTP Header Suppression Indicator is a Boolean parameter that describes usage of the RTP header suppression mode as defined in Section 4.2.3 above. Its default value is FALSE. Note: If this parameter is set to TRUE, then the values of RTP-related parameters discussed in Section 5.2.3 below become irrelevant. 5.2.2. Payload Bytes This parameter has been defined in [MARTINI-TRANS]. In order to establish a UCESoPSN-based PW, the following conditions MUST be met: 1. The number of payload bytes MUST be the same for both directions of the PW 2. The size of the resulting PW packet (including all the headers) SHOULD NOT exceed the path MTU between the participating PEs as provided by the Carrier layer. 5.2.3. RTP-related Parameters 5.2.3.1. Payload Type One PT value MUST be allocated from the range of dynamically allocated payload types for each UCESoPSN PW for use in the data packets: o The same value MUST be allocated for both directions of the PW Vainshtein et al. Expires March 2003 [Page 12] TDM Circuit Emulation Service over PSN October 2002 o Ingress PE MUST set the PT in the RTP header of all the data packets to the allocated value o Egress PE MAY use this value to detect malformed packets. Note: The same PT value may be allocated for multiple PWs. 5.2.3.2. Timestamp Resolution This parameter encodes the rate of the clock used for setting timestamps in RTP headers as a multiple of the basic 8 kHz rate. 5.2.3.3. Synchronization Source ID The same 32-bit SSRC value MUST be assigned to all the data packets of a given direction of a UCESoPSN PW. The CE-bound direction of the IWF MAY be use this value for misconnection detection, especially if such a service is not provided by the PSN and/or multiplexing layer(s). 5.2.3.4. Timestamp Generation Mode Encoding of the following values corresponding to modes described in Section 4.2.1 SHOULD be supported: o Absolute (1) o Differential (2). The Differential mode can be used only if both PE devices support it. 5.3. End Service Inactivity Behavior While the PW is inactive, the PE MUST send AIS to its local CE. 5.4. Description of the IWF operation Once the PW is set up, the UCESoPSN IWF operates in the following manner. 5.4.1. PSN-bound Direction o The necessary NSP operations are performed o The end service data is packetized in accordance with the number of payload bytes specified o Sequence numbers and, in the basic UCESoPSN format, timestamps representing the selected synchronization clock are inserted in the UCESoPSN headers o UCESoPSN, multiplexing and PSN headers are prepended to the packetized service data o Resulting packets are transmitted via the PSN o If the PE detects any outage of the incoming end service that natively would result in sending the "downstream AIS", the UCESoPSN IWF MUST set the local AIS indication flag (bit A) in the control word. The packet payload MAY be omitted in order to conserve PSN bandwidth Vainshtein et al. Expires March 2003 [Page 13] TDM Circuit Emulation Service over PSN October 2002 o If the PE detects an Idle Code condition of the incoming T3 end service, the UCESoPSN IWF MUST set the local Idle Code indication flag (bit D) in the control word. The packet payload MAY be omitted in order to save the PSN bandwidth o If the PE detects an RAI condition of the incoming end service, the UCESoPSN IWF MAY set the RAI flag (bit X) in the control word. Local AIS and Idle Code indications in the UCESoPSN control word provide for the following functionality: o Ability to distinguish between intra-PSN and extra-PSN faults as causes of outages of the emulated service o Ability to conserve PSN bandwidth (but not its switching capacity) by not sending invalid data across the PSN. The techniques to save the PSN switching capacity in case of an end service outage are left for further study. 5.4.2. CE-bound Direction The CE-bound IWF MUST include a jitter buffer that accumulates data from incoming UCESoPSN packets, and, in the basic CESoPSN format, their respective timestamps. The length of this buffer SHOULD be configurable to allow adaptation to various network delay behavior patterns. The size of the jitter buffer is a local parameter of the UCESoPSN IWF. Initially the jitter buffer is filled with the appropriate inactivity (AIS or Idle) code. Upon initialization, the IWF performs the following functions. o Begins reception of incoming UCESoPSN packets. PSN and multiplexing layer headers are stripped from the received packets, and packetized TDM data from the received packets is stored in the jitter buffer. o Continues to play out its appropriate inactivity code into its end service as long as the jitter buffer has not yet accumulated sufficient amount of data o Once the jitter buffer contains sufficient amount of data (usually half of its capacity), the IWF starts to play out this data to its end service in accordance with its (locally defined) 8 kHz transmission clock. If transmission clock needs to be recovered from the PW and RTP had not been suppressed, the timestamps of data packets SHOULD be used for correcting initial transmission clock frequency in accordance with the specified mode of their generation. UCESoPSN packets marked with an AIS indication in the control word MUST be replaced with the appropriate amount of AIS. UCESoPSN packets marked with an Idle Code indication in the control world (for PWs carrying unstructured T3 service) MUST be replaced with the appropriate amount of the T3 Idle Code. The CE-bound direction of the IWF: Vainshtein et al. Expires March 2003 [Page 14] TDM Circuit Emulation Service over PSN October 2002 o Performs detection, correlation and handling of UCESoPSN faults as described in Section 6.5 below o Collects the PW Performance Monitoring data as defined in Section 6.6 below 5.5. UCESoPSN Defects 5.5.1. Misconnection Some combinations of PSN and multiplexing layers (see Annex A) inherently provide for detection of packets that do not belong to the PW ('stray packets'). UCESoPSN MAY use the SSRC field in the RTP header for detection of 'stray packets' even if such a capability is provided by the specific combination of PSN and multiplexing layers. This capability is not available if the RTP header is suppressed. Regardless of the way in which a stray packet has been detected: o It MUST be discarded by the CE-bound IWF o A counter of 'stray packets' must be incremented If reception of stray packets persists, the Misconnection alarm should be reported to the management system. The IWF mechanisms for detection of lost packets (e.g., expected next sequence number) MUST NOT be affected by reception of 'stray packets'. 5.5.2. Re-Ordering and Loss of Packets UCESoPSN implementations SHOULD use the sequence number in the RTP header and expected rate of transmission of data packets for detection of out-of-order delivery and packet loss. Alternatively the optional sequence number in the UCESoPSN control word MAY be used for this purpose. In particular, implementations MAY maintain the next expected sequence number value that would be: o Advanced every time a packet belonging to this PW with an equal or greater (mod 65536) sequence number has been received or a timeout defined by the expected packet arrival rate has expired o Used as the center of a sliding window for packet reordering. The size of this window SHOULD be limited by the size of the jitter buffer. Out-of-order packets that cannot be reordered (e.g. because their sequence numbers are out of the sliding window mentioned above) MUST be considered as lost. If loss of one or more UCESoPSN packets has been detected at the egress of the UCESoPSN PW, its jitter buffer MUST be filled with the appropriate amount of "replacement packets". The content of these packets is a local matter and can be chosen in accordance with the specific CE requirements. Packets containing the appropriate AIS code MAY be used as replacement packets. In addition: Vainshtein et al. Expires March 2003 [Page 15] TDM Circuit Emulation Service over PSN October 2002 o A counter of lost packets must be incremented o If the counter exceeds some threshold the Remote Lost Packets Indication flag (bit R) MUST be set in the next packet to be sent in the opposite direction of the PW. If the packet loss condition persists, an alarm SHOULD be sent to the management system. 5.5.3. Malformed Packets An UCESoPSN PW detects a malformed packet using the following rules: o The PT value in its RTP header does not correspond to the PT value allocated for this PW. This rule cannot be used if the RTP header is suppressed o The actual packet payload size (inferred from the data link, PSN or multiplexing layer) does not match the payload size defined for the packets of this type in this PW. If a malformed in-order packet has been received at the egress of a UCESoPSN PW, then: o The packet MUST be discarded and appropriate amount of AIS (or Idle Code) inserted in the jitter buffer o A counter of malformed packets must be incremented o If the payload mistype condition persists, an appropriate alarm SHOULD be sent to the management system. 5.5.4. Loss of Synchronization The UCESoPSN IWF MAY detect two types of loss of synchronization errors: 5.5.4.1 Jitter Buffer Overrun This fault is detected if the jitter buffer at the PW egress cannot accommodate the newly arrived UCESoPSN packet in its entirety. If the jitter buffer overrun condition persists, an appropriate alarm SHOULD be sent to the management system. 5.5.4.2 Jitter Buffer Underrun This fault SHOULD be detected if the jitter buffer at the PW egress becomes empty before arrival of a new UCESoPSN packet while loss of packets has not been detected. UCESoPSN Implementations are not required to distinguish between the packet loss condition and the jitter buffer underrun. If the jitter buffer underrun condition persists, an appropriate alarm SHOULD be sent to the management system. Vainshtein et al. Expires March 2003 [Page 16] TDM Circuit Emulation Service over PSN October 2002 5.6. Performance Monitoring 5.6.1. Errored Data Blocks [G.826] defines the concept of an errored data block that serves as the basis for collection of performance monitoring parameters. It also defines the size of the data block for most TDM circuits. The following definitions of error events and errored data blocks for UCESoPSN provide for collection of [G.826]-compatible performance monitoring parameters: o An error event is insertion of a single native service frame of inactivity code into the jitter buffer if it does not stem from receiving a UCESoPSN packet with an AIS or Idle Code indication o An errored data block is a data block defined in accordance with [G.826] that has experienced at least one error event o A defect is insertion of a contiguous sequence of native service frames of inactivity code into the jitter buffer if it does not stem from receiving a UCESoPSN packet with an AIS or Idle Code indication and if the length of this sequence exceeds the limits defined by the defect detection rules of the emulated service. 5.6.2. Errored, Severely Errored and Unavailable Seconds The definition of an errored data block presented above can be used to define Errored Seconds, Severely Errored Seconds and Unavailable Seconds in accordance with [G.826]. 5.7. QoS Issues If the PSN providing connectivity between PE devices is Diffserv- enabled and implements EF PHB (see [RFC3246]), all the UCESoPSN data packets should be marked for EF PHB at ingress. Such an arrangement decreases packet inter-arrival jitter as well as prevents packet loss due to congestion in the PSN and hence improves availability of the emulated service and decreases latency introduced by the TDM circuit emulation. 6. RTP Payload Format Considerations In accordance with guidelines specified in [RFC2736], the following issues are addressed by this specification: 6.1. Resilience to moderate loss of individual packets The impact of individual packet loss may be decreased by decreasing the packet payload size (with associated loss of efficiency). 6.2. Ability to interpret every single packet Vainshtein et al. Expires March 2003 [Page 17] TDM Circuit Emulation Service over PSN October 2002 This requirement is met in the RECOMMENDED mode of packetization when each UCESoPSN packet carries a multiple of the native circuit frame of the carried service. 6.3. Non-usage of the RTP Header Extensions This recommendation is met, since RTP-wise, the UCESoPSN Control Word is part of the RTP payload. Alignment with this requirement facilitates usage of standard header compression mechanisms if UCESoPSN uses UDP/IP as its PSN and multiplexing layers. 6.4. Compression of RTP headers Existing relevant standards ([RFC2508], [RFC3095]) deal with compression of RTP/UDP/IP headers on specific P2P links. Compression techniques defined in these documents are fully applicable for UCESoPSN if it uses UDP/IP as PSN and multiplexing layers respectively. Standard compression of UCESoPSN/UDP/IP headers will be very effective, since: o Value of the SSRC field in the UCESoPSN header of data packets remains constant for the duration of a UCESoPSN session o Value of the Timestamp field in the UCESoPSN header is usually incremented by a fixed value from packet to packet o UCESoPSN control word is NOT defined as RTP header extension. 7. Congestion Control (RFC 2914) Conformance UCESoPSN PWs carry constant bit rate (CBR) services. These services, by definition, cannot behave in a TCP-friendly manner prescribed by [RFC2914] under congestion while retaining any value for the user. Devices implementing UCESoPSN and using IP as their PSN layer: o MUST set the ECN bits of the IP header (see [RFC3168]) to non- ECT ('00') value at ingress (to prevent routers in the network from setting them to the CE ('11') value) o SHOULD ignore these bits at egress. 8. FFS Issues Note: This section will be removed from the final revision of the document. The following issues will be addressed in the future revisions of this document: o Techniques for saving the PSN switching capacity when the PW experiences an end service outage or does not carry any valid data o Effect of timestamp resolution on quality of clock recovery in Differential mode Vainshtein et al. Expires March 2003 [Page 18] TDM Circuit Emulation Service over PSN October 2002 o Recommended defaults for all the configurable parameters of the PW (per service type). 9. Security Considerations This document does not affect the underlying security issues of specific PSN. In addition, it defines misconnection detection capabilities of UCESoPSN. These capabilities increase resilience of UCESoPSN to misconfiguration and some types of DoS attacks. 10. Applicability Statement UCESoPSN is an encapsulation layer intended for carrying unstructured TDM circuits (E1, T1, E3 and T3) over PSN. UCESoPSN allows carrying both data and clock of TDM circuits across multiple types of PSN. UCESoPSN does not presume availability of a global synchronous clock at the ends of a PW. This makes it suitable for Asynchronous Carriers' Carrier applications. PE devices implementing UCESoPSN do not require local oscillators of quality that is better than natively required for the carried service. UCESoPSN performs only the minimally necessary mapping of the TDM data (in case of an octet-aligned unstructured T1 service), or none at all, hence minimizing overhead at the payload layer. UCESoPSN SHOULD use RTP for carrying the clock across the PSN. The additional control word is a "payload format header" and hence standard header compression techniques for RTP/UDP/IP profile over slow and/or error-prone links are fully applicable to UCESoPSN PWs. UCESoPSN allows the PSN bandwidth conservation by carrying only AIS and/or Idle Code indications instead of data. Being a constant bit rate (CBR) service, UCESoPSN cannot provide TCP- friendly behavior under network congestion. UCESoPSN allows collection of TDM-like faults and performance monitoring parameters hence emulating 'classic' carrier services of TDM circuits (e.g., SONET/SDH). Similarity with these services is increased by the UCESoPSN ability to carry 'far end error' indications. UCESoPSN provides for a carrier-independent ability to detect misconnections and malformed packets. This feature increases resilience of the emulated service to misconfiguration and DoS attacks. Vainshtein et al. Expires March 2003 [Page 19] TDM Circuit Emulation Service over PSN October 2002 UCESoPSN provides for detection of lost packets and hence allows to distinguish between the PSN problems and ones beyond the PSN as causes of outages of the emulated service. Faithfulness of a UCESoPSN PW may be increased if the carrying PSN is Diffserv-enabled and implements EF PHB. UCESoPSN carries indications of outages of incoming attachment circuit across the PSN and provides of detection of lost packets. The combination of these abilities provides for effective fault isolation. UCESoPSN 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 UCESoPSN increase resilience of the emulated service to fast PSN rerouting events o Remote indication of lost packets is carried backward across the PSN from the receiver (that has detected loss of packets) to transmitter. Such an indication MAY be used as a trigger for activation of proprietary service-specific protection mechanisms o Appropriate local definition of replacement packets improves resilience of the emulated end-to-end (i.e. CE-to-CE) services to occasional loss of packets in the PSN. 11. IANA Considerations This specification requires assignment of new PW Types for UCESoPSN PWs as described in Section 6.1. 12. Intellectual Property Disclaimer This document is being submitted for use in IETF standards discussions. Axerra Networks, Inc. has filed one or more patent applications relating to the UCESoPSN technology outlined in this document. Axerra Networks, Inc. will grant free unlimited licenses for use of this technology to the users who will register and sign up at the Axerra web site. RAD Data Communcations, Ltd. has filed one or more patent applications that may relate to the technology outlined in this document. RAD hereby grants free unlimited license for use of its intellectual property to the extent required for compliance with this document. ACKNOWLEDGEMENTS We express deep gratitude to Stephen Casner who provided many valuable inputs. Vainshtein et al. Expires March 2003 [Page 20] TDM Circuit Emulation Service over PSN October 2002 We thank Maximilian Riegel, Sim Narasimha, Tom Johnson, Yaron Raz, Ashwin Moranganti, Ron Insler, and Ronen Shashoua for valuable feedback. We thank Hugo Silberman and Alik Shimelmits for many fruitful discussions. References [PWE3-REQ] XiPeng Xiao et al, Requirements for Pseudo Wire Emulation Edge-to-Edge (PWE3), Work in Progress, June-2002, draft-ietf-pwe3- requirements-03.txt [PWE3-TDM-REQ] Maximilan Riegel et al, Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks (PSN), Work in Progress, June 2002, draft-riegel-pwe3-tdm-requirements-00.txt [PWE3-ARCH], S. Bryant and P. Pate, PWE3 Architecture, Work in Progress, October 2002, draft-ietf-pwe3-arch-00.txt [PWE3-SONET] Andrew G. Malis et al, SONET/SDH Circuit Emulation over Packet (CEP), Work in progress, July 2002, draft-ietf-pwe3-sonet-00.txt [KOMPELLA] MPLS-based Layer 2 VPNs, Work in Progress, July 2001, draft- kompella-ppvpn-l2vpn-00.txt [PWE3-CONTROL] L. Martini, N. El-Aawar, E. Rosen, Transport of Layer 2 Frames Over MPLS, Work in progress, August 2002, draft-ietf-pwe3- control-protocol-00.txt [L2TPv3] J.Lau et al, Layer Two Tunneling Protocol "L2TP", Work in progress, October 2001, draft-ietf-l2tpext-l2tp-base-01.txt [RFC1122] R. Braden (ed.), Requirements for Internet Hosts -- Communication Layers, RFC 1122, IETF, 1989 [RFC1889] H. Schulzrinne et al, RTP: A Transport Protocol for Real-Time Applications, RFC 1889, IETF, 1996 [RFC2119] S.Bradner, Key Words in RFCs to Indicate Requirement Levels, RFC 2119, IETF, 1997 [RFC2434] T. Narten, H. Alvestrand, Guidelines for Writing an IANA Considerations Section in RFCs, RFC 2434, IETF, 1998 [RFC2474] K. Nichols et al., Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474, IETF, 1998 [RFC2508] S.Casner, V.Jacobson, Compressing IP/UDP/RTP Headers for Low- Speed Serial Links, RFC 2508, IETF, 1999 [RFC2736] M. Handley, C. Perkins, Guidelines for Writers of RTP Payload Format Specifications, RFC 2736, IETF, 1999 Vainshtein et al. Expires March 2003 [Page 21] TDM Circuit Emulation Service over PSN October 2002 [RFC3246] Bruce Davie (ed.), An Expedited Forwarding PHB.RFC 3246.IETF, 2002 [RFC2833] H. Schulzrinne, S. Petrack, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals. RFC 2833, IETF, 2000 [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, IETF, 2000 [RFC3095] C.Bormann (Ed.), Robust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed, RFC 3095, IETF, 2001 [RFC3140] D. Black et al, Per Hop Behavior Identification Codes, RFC 3140, IETF, June 2001 [RFC3168] K. Ramakrishnan, S. Floyd, D. Black, The Addition of Explicit Congestion Notification (ECN) to IP, RFC 3168, IETF, 2001 [RTP-TYPES] RTP PARAMETERS, http://www.iana.org/assignments/rtp- parameters [G.702] ITU-T Recommendation G.702 (11/88) - Digital Hierarchy Bit Rates [G.703] ITU-T Recommendation G.703 (10/98) - Physical/electrical characteristics of hierarchical digital interfaces [G.707] ITU-T Recommendation G.707 (10/00) - Network Node Interface for Synchronous Digital Hierarchy (SDH) [G.802] ITU-T Recommendation G.802 (11/88) - Interworking between networks based on different digital hierarchies and speech encoding laws [G.826] ITU-T Recommendation G.826 (02/99) - Error performance parameters and objectives for international, constant bit rate digital paths at or above the primary rate [I.363.1] ITU-T Recommendation I.363.1 (08/96) - B-ISDN ATM Adaptation Layer (AAL) specification: Type 1 [T1.105] ANSI T1.105-1991. Digital Hierarchy - Optical Interface Rates and Format Specifications (SONET} Authors' addresses Alexander ("Sasha") Vainshtein Axerra Networks 24 Raoul Wallenberg St. Tel Aviv 69719, Israel email: sasha@axerra.com Vainshtein et al. Expires March 2003 [Page 22] TDM Circuit Emulation Service over PSN October 2002 Yaakov (Jonathan) Stein RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719, Israel Email: yaakov_s@rad.co.il Israel Sasson Axerra Networks 24 Raoul Wallenberg St. Tel Aviv 69719, Israel email: israel@axerra.com Akiva Sadovski Axerra Networks 24 Raoul Wallenberg St. Tel Aviv 69719, Israel email: akiva@axerra.com Eduard Metz Thrupoint Paasheuvelweg 16, 1105 BH Amsterdam, Netherlands email: eduard.metz@hetnet.nl, emetz@thrupoint.net Tim Frost Zarlink Semiconductor Tamerton Road, Roborough, Plymouth, PL6 7BQ, UK email: tim.frost@zarlink.com Prayson Pate Overture Networks P. O. Box 14864, RTP, NC, USA 27709 Email: prayson.pate@overturenetworks.com Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Vainshtein et al. Expires March 2003 [Page 23] TDM Circuit Emulation Service over PSN October 2002 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. ANNEX A. UCESoPSN ENCAPSULATION FOR DIFFERENT TYPES OF PSN A1. IP PSN UDP/IP can be used for conveying UCESoPSN, in which case unused UDP ports must be allocated at both PE nodes terminating a PW as part of the PW establishment process IP and UDP headers MUST be prepended to each UCESoPSN packet. These packets will be transmitted by each PE node to its peer using standard IP routing mechanisms. UDP flows represent a multiplexing layer with limited ability to detect misconnections. As a consequence, SSRC-based misconnection detection by UCESoPSN MAY be disabled. IP represents a Carrier layer with inherent ability to infer the payload size from the header. As a consequence, detection of malformed packets SHOULD take the actual payload size into consideration. By default, manual signaling MAY be used for setup and teardown of UCESoPSN PWs over UDP flows. As a consequence, parameters defined in Section 6 should be incorporated into to the appropriate service- specific MIB module. A2. MPLS PSN Note: The text below does not define a generic RTP/MPLS stack. Such a work is clearly out of scope of this document. This section is concerned with the case of MPLS being used as both the PSN and multiplexing layer for the UCESoPSN PW. In this case, UCESoPSN packet MUST be prepended with an MPLS label stack including: Vainshtein et al. Expires March 2003 [Page 24] TDM Circuit Emulation Service over PSN October 2002 1. A VC label entry (see [MARTINI-TRANS] or [KOMPELLA]). This entry acts as the multiplexing layer header. It MUST be present in the stack and MUST be marked as residing at the bottom of the stack 2. A tunnel label entry. This label, if present, acts as the PSN header and MUST immediately precede the VC label entry. It MAY be omitted in some situations. This combination of PSN and multiplexing layers provides neither frame length information nor ability to detect misconnections. The former is not necessary for UCESoPSN but limits ability to detect malformed packets in case of a very short packet payload. The latter SHOULD be compensated by employing the SSRC-based misconnection detection. MPLS tunnels are conventionally established using various signaling protocols. As a consequence, parameters used for setup and teardown of UCESoPSN tunnels should be mapped to data elements of these protocols. 3. L2TP PSN Note: The text below does not define a generic RTP/L2TPv3 stack. Such a work is clearly out of scope of this document. UCESoPSN packets may be carried in L2TPv3 tunnels over IP (see [L2TPv3]) that would act as an alternative multiplexing layer over IP. Since L2TPv3 provides both data and control plane for tunnel establishment, parameters describing payload and encapsulation layers should be defined as AVPs to allow single-ended setup and teardown of UCESoPSN PWs. L2TPv3 tunnels represent a multiplexing layer with an optional ability to detect misconnections using 32-bit or 64-bit "cookies". As a consequence, the PSN operator may choose between the L2TPv3-based and SSRC-based misconnection detection techniques for UCESoPSN PWs. IP represents a PSN layer with inherent ability to infer the payload size from the header. As a consequence, malformed packet detection should consider actual payload size. Vainshtein et al. Expires March 2003 [Page 25]