Internet Engineering Task Force Internet Draft Rajesh Kumar Document: draft-rajeshkumar-mmusic-sdp-atm-01.txt Mohamed Mostafa March 1, 2000 Cisco Systems Expires: September 1, 2000 Extension of the Session Description Protocol (SDP) for ATM-based Narrowband Telephony STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 extends the Session Description Protocol (SDP) described in RFC2327 for narrowband telephony applications that use AAL1 or AAL2. The list of extensions is meant to be exhaustive. Individual applications can use subsets of these extensions. Rajesh Kumar, Mohamed Mostafa [Page 1] 1. Introduction SDP will be used in conjunction with a media control protocol such as Megaco (draft-ietf-megaco-reqs-10.txt) or MGCP (RFC2705) to communicate the information needed to set-up narrowband telephony connections through an ATM fabric. These narrowband telephony connections include voice connections, voiceband data connections, clear channel circuit emulation connections and demodulated, baseband data connections for facsimile relay and modem relay. These extensions are meant to address the following narrowband telephony applications: * Applications in which a new SVC is set-up for each narrowband telephony connection. These SVCs could be AAL1 SVCs or single-CID AAL2 SVCs. * Applications in which existing PVC resources are assigned to narrowband telephony connections. These resources could be AAL1 PVCs, AAL2 single-CID PVCs or channels within multiplexed AAL2 PVCs. Generally, the SDP session description will be constructed by an ATM network element such as a media gateway or an ATM or AAL2 switch and will be sent to a connection peer via a bearer-independent connection control mechanism such as tunneling through an ISUP fabric. ATM network elements will used the SDP information to construct bearer signaling messages based on Q.2931 and Q.2630.1. These messages are used for ATM bearer connection establishment and the binding of an ATM bearer connection or channel to a telephony connection. It is also possible for the media gateway controller (call agent) to construct, modify or append to the SDP session description. 2. Conventions used in this document This document uses all the syntactic conventions of standard SDP as defined in RFC2327. The SDP protocol (RFC2327) requires that non-standard attributes and codec names use an "X-" prefix. In this internet draft, the "X-" prefix is used consistently for codec names (Table 1) that have not been registered with IANA. However, this prefix is not used for the extension SDP attributes defined in this document, since these are targeted for standardization. Since some implementations might not use these conventions, it is suggested that any parser/builder designed to this extensions Rajesh Kumar, Mohamed Mostafa [Page 2] document should accept codec names and attribute names with or without the "X-" prefix. 3. Capabilities Provided by SDP extensions To support these applications, the SDP extensions in this document provide the following session establishment capabilities: * Identification by an ATM network element of its own address, in one of several possible formats. A connection peer can initiate SVC set-up to this address. * Identification of the ATM bearer connection that is to be bound to the narrowband telephony connection. This is either a VCC in AAL1 applications or a channel (identified by a CID) in AAL2 applications. This is useful in PVC applications. * In AAL1 applications, declaration of a set of payload types that can be bound to the ATM bearer connection. RTP payload types that have been registered with IANA are re-used for AAL1. In the manner of standard SDP, unregistered payload types are mapped dynamically, * In AAL2 application, declaration of a set of profiles that can be bound to the ATM bearer connection. A mechanism for dynamically defining custom profiles within the SDP session description is included. This allows the use of custom profiles for connections that span multi-network interfaces. * A means of correlating narrowband telephony connections with underlying ATM bearer connections. The backbone network connection identifier or bnc-id specified in ITU Q.BICC standardization work is used for this purpose. In order to provide a common SDP base for applications based on ISUP+/Q.BICC and SIP/SIP+, the neutral term 'eecid' is used in lieu of 'bnc-id' in the SDP session descriptor. * A means of specifying the explicit mapping of one codec type and one packetization period into a service type. Service types are voice, voiceband data and facsimile. This is useful in determining the encoding to use when the connection is upspeeded in response to modem or facsimile tones. * A means of describing the QoS class, traffic parameters and QoS parameters of the underlying ATM bearer connection. Rajesh Kumar, Mohamed Mostafa [Page 3] 4. Format of the ATM Session Description Session Descriptions for Narrowband Telephony over ATM contain the following lines: v= (protocol version) o= (origin) s= (session name) c= (connection information) t= (timestamp) m= (media information and transport address) a= (media attribute) A session description for ATM-based narrowband telephony has exactly one of each of the following lines: 'v', 'o', 's', 'c', 't' and 'm'. These are mandatory per RFC2327. The 'a' line is optional. This line can be omitted. Also, there can be multiple 'a' lines in an ATM session description. The order of lines in an ATM session description is exactly as depicted above. The 'o', 's' and 't' lines are included for strict conformance with RFC2327. It is recognized that these lines do not carry useful information in some ATM-based narrowband telephony applications. For maximum interoperability, SDP parsers should not reject session descriptions that are without these lines. An ATM network element or call agent can propose several session descriptions, each of which begins with a protocol version ('v') line. Each proposed session description is an alternate method of realizing the connection. These options are trimmed down as the connection establishment progresses. Rajesh Kumar, Mohamed Mostafa [Page 4] 5. Structure of the Session Description Lines 5.1 The Origin Line The origin line for an ATM-based narrowband telephony session is structured as follows: o= The is set to '-'. The can be set to one of the following: * a Call ID, known from a signaling or control protocol. * an NTP timestamp referring to the moment when the SDP session descriptor was created. The refers to the version of the SDP session descriptor (not that of the SDP protocol). This is can be set to one of the following: * '0' * an NTP timestamp referring to the moment when the SDP session descriptor was modified. If the SDP session descriptor has not been modified by an intermediate entity (such as a call agent), then the timestamp will be the same as the timestamp, if any. The in ATM-based narrowband telephony session descriptions can be one of the following: 'ATM', 'AAL1', 'AAL2' or 'AAL5_FRF11'. The generic value 'ATM' is adequate since the adaptation type and higher-layer protocols are indicated elsewhere in the session description. The and parameters are identical to those for the connection information ('c') line. As with the 'c' line, these can be omitted where appropriate. Alternatively, each of these parameters can be set to a '-' when it is not particularly meaningful or necessary to specify the ATM address. 5.2 The Session Name Line In general, the session name line is structured as follows: s= For ATM-based narrowband telephony sessions, the parameter is either empty or is set to a '-'. The resulting lines are: s= Rajesh Kumar, Mohamed Mostafa [Page 5] s=- 5.3 The Connection Information Line The connection information line for ATM-based narrowband telephony sessions is structured as follows: c=ATM The refers to the local ATM address rather than the ATM address of the remote peer. See the description of the media information line below for a means of indicating the ATM address of the remote peer. The can be NSAP, E164 or GWID. The format depends on the . NSAP: If the ATMaddressType is NSAP, the ATMaddress is expressed as a string of 20 octets in dotted hex form. The last octet of the NSAP address is the 'selector' field that is not used for ATM addressing and is available for non-standard use. The prior six octets of the NSAP are an IEEE 802 MAC address assigned to the gateway. For example: c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00 E164: If the ATMaddressType is E164, the ATMaddress is expressed as decimal numbers with up to 15 digits. For example: c=ATM E164 9738294382 GWID: If the ATMaddressType is GWID meaning that the address is a private Voice Gateway identifier (unique within context of network), the ATMaddress is expressed as ASCII string ("A"-"Z", "a"-"z", "0"- "9",".","-","_"). For example: c=ATM GWID officeABCmgx101vism12 The connection information line is always present in an SDP session descriptor. However, if there is no address to transmit, this line can be represented in one of the following equivalent ways: c=ATM c=ATM - - This might be used when the address is known a priori. Rajesh Kumar, Mohamed Mostafa [Page 6] 5.4 The Timestamp Line The timestamp line for an SDP session descriptor is structured as follows: t= For ATM-based narrowband telephony sessions, the parameter can be made equal to the NTP timestamp (if any) used for the in the 'o' line. It can also be set to 0 indicating its irrelevance. The parameter is set to 0 in the ATM-based narrowband telephony context. 5.5 Media Information Line for AAL1 sessions The media information line for AAL1-based narrowband telephony sessions is structured as follows: m=audio AAL1/AVP ... Note that it is not possible to make this line identical to the 'm' line in VoAAL2 due to basic differences between the two applications. The parameter can be in one of the following formats: * * -/ * // where the number of slashes and/or the application context are used to differentiate between the various options. Within the SDP media information line, , , and are decimal numbers. The and are identical to their definitions above for the connection information line with the difference that this address refers to the remote peer in the media information line. A '$' notation implies 'any'. A '$' can be used in lieu of , , , or the entire virtualConnectionId parameter. Additionally, a '$' can be used in lieu of: * the hyphenated concatenation of the remote peer and * the remote peer but not the . Rajesh Kumar, Mohamed Mostafa [Page 7] There are contexts such as SVC-based applications where there is no need to communicate the parameter across the call agent - media gateway interface. In these contexts, it is sufficient to use a '$', '$/$' or '$/$/$' for the parameter. When the network uses PVCs the VCCI values are pre-provisioned. If connections are established via SVCs or S/PVCs, the VCCI is selected from the list of available VCCIs. The VCCI can be signaled end-to- end within the Generic Information Transport (GIT) as part of the ITU Recommendation Q.2931 Setup message per ITU Recommendation Q.2941.2. Q.2941.2 proposes that bit 16 of a 16 bit VCCI be used to prevent glare in the allocation of VCCIs from either end. This Q.2941-based scheme is not adequate for preventing glare when a limited number of PVCs are dynamically assigned to narrowband telephony connections on a call-by-call basis. For this dynamic PVC context, a mechanism for glare reduction such as assigning the lowest available values from different ends is needed. The parameter is used to identify the physical trunk port on a stand-alone gateway or on a multiplexer into which the gateway is plugged as a tributary module. The VPI and VCI have their usual ATM connotation. Although RTP encapsulation defined in rfc1889 is not used, the payload type variables are used exactly as defined in rfc1890. Hence, the protocol used for Voice-over-AAL1 is identified as AAL1/AVP in the media information line. Following the text string 'AAL1/AVP', there is a list of payload types. The ordering of these payload types (preferred codecs before less favored ones) can indicate preference is some applications. These can be either statically assigned or dynamically mapped payload types. Encodings that are not statically mapped to payload types by IANA are to be dynamically mapped at the time of connection establishment to payload types in the decimal range 96- 127. The SDP 'rtpmap' attribute (renamed 'atmmap') is used for this purpose. The following are examples of the use of the media information line in the descriptions of AAL1 narrowband telephony sessions. Example 1: m=audio 27 AAL1/AVP 18 0 96 a=atmmap:96 G727-32 implies that the AAL1 VCCI=27 and that the supported encoding formats are G.729 (or G.729a), PCM Mu-law and 32 kbps G.727. Example 2: m=audio 3/4/50 AAL1/AVP 8 15 Rajesh Kumar, Mohamed Mostafa [Page 8] implies that the AAL1 virtual circuit used has VPI=4, VCI=50 and is on trunk port #3. Further, it implies that the encoding formats are G.711 A-law and G.728. Example 3: m=audio $ AAL1/AVP 8 15 implies that any AAL1 VCC may be used (subject to glare rules). Example 4: m=audio 2/6/$ AAL1/AVP 8 15 implies that any VCI on VPI= 6 of trunk port #2 may be used. 5.6 Media Information Line for AAL2 sessions The media information line for AAL2-based narrowband telephony sessions is structured as follows: m=audio ... ... ... In certain applications, the ordering of profiles (preferred profiles before less favored ones) might imply a preference. In this case, the profiles associated with different profile types can be interspersed rather than grouped together as in the definition above. Note that it is not possible to make this line identical to the 'm' line in Voice-over-AAL1 due to basic differences between the two applications. The parameter can be in one of the following formats: * / * -// * /// * /// * // where the number of slashes and/or the application context are used to differentiate between the various options. Within the SDP media information line, , , , , and are decimal numbers. The and are identical to the definitions above for the connection information line with the difference that this address refers to the remote peer in the media information line. Rajesh Kumar, Mohamed Mostafa [Page 9] A '$' notation implies 'any'. A '$' can be used in lieu of , , , , or the entire virtualConnectionId parameter. Additionally, a '$' can be used in lieu of: * the hyphenated concatenation of the remote peer and * the remote peer but not the . There are contexts such as SVC-based applications where there is no need to communicate the parameter across the call agent - media gateway interface. In these contexts, it is sufficient to use a '$', '$/$', '$/$/$' or '$/$/$/$' for the parameter. When the network uses PVCs the VCCI values are pre-provisioned. If connections are established via single-CID SVCs or S/PVCs, the VCCI is selected from the list of available VCCIs. The VCCI can be signaled end-to-end within the Generic Information Transport (GIT) as part of the ITU Recommendation Q.2931 Setup message per ITU Recommendation Q.2941.2. Q.2941.2 proposes that bit 16 of a 16 bit VCCI be used to prevent glare in the allocation of VCCIs from either end. This Q.2941-based scheme is not adequate for preventing glare when a limited number of single-CID PVCs are dynamically assigned to narrowband telephony connections. For this dynamic PVC context, a mechanism for glare reduction such as assigning the lowest available values from different ends is needed. The in AAL2 has the same value on both gateways that are part of the connection. It is expected that both gateways may be required to select AAL2 channels for different calls dependent on the direction from which the calls arrived. Therefore, the possibility will occur that gateways may be selecting the channel for two separate calls simultaneously. In this context, a mechanism for glare reduction such as assigning the lowest available values from different ends is needed. The parameter is used to identify the physical trunk port on a stand-alone gateway or on a multiplexer into which the gateway is plugged as a tributary module. The parameter refers to the bearer connection group as defined in Q.2630.1. The , , and have their usual ATM connotation. The parameter indicates the type of profile. It is expressed in the format AAL2/ where is an organizationally unique identifier. Currently defined values of are 'ITU', 'ATMF' and 'custom'. The resulting profileType values indicate the following: * AAL2/ITU indicates that AAL2 is used as the adaptation layer and the profiles are defined by ITU in specification I.366.2. Rajesh Kumar, Mohamed Mostafa [Page 10] * AAL2/ATMF indicates that AAL2 is used as the adaptation layer and the profiles are defined by the ATM Forum in specification AF-VTOA-0113. * AAL2/custom indicates that AAL2 is used as the adaptation layer and the profiles are non-standard custom profiles. The parameter is expressed as a decimal number. The value of the profile for profiles of the type AAL2/ITU or AAL2/ATMF are in range 0-255 in accordance with ITU-T I.366.2 Annex P and AF-VTOA- 0113. For example, the media information line may look like: m=audio 123/5 AAL2/ITU 1 This media line indicates that the media contains audio. The VCCI for the AAL2 connection is decimal 123 and the CID is decimal 5. The AAL2 connection uses ITU profile 1 as defined in I.366.2. m=audio $ AAL2/ITU 8 AAL2/custom 100 AAL2/ITU 1 implies that any AAL2 VCC may be used (subject to glare rules). A preferentially ordered list of profiles is suggested for this connection with AAL2/ITU 8 having the highest priority. 5.7 The Media Attribute Lines In an SDP line sequence, the media information line 'm' is followed by one or more media attribute or 'a' lines. Media attribute lines are per the format below: a=: or a= In general, media attribute lines are optional except when needed to qualify the media information line. This qualification is necessary when the "m" line for an AAL1 session specifies a payload type that needs to be dynamically mapped. The 'atmmap' media attribute line defined below is used for this purpose. The following media attribute lines are defined for use in descriptions of ATM-based narrowband telephony sessions: * The attributes defined in RFC2327 which allow indication of the direction in which a session is active. These are a=sendonly, a=recvonly, a=sendrecv, a=inactive. * The 'Ptime' attribute defined in RFC2327. It indicates the packet period. Rajesh Kumar, Mohamed Mostafa [Page 11] * The 'atmmap' attribute. In the AAL1 context, this is used to dynamically map payload types into codec strings. * The 'eecid' attribute. This stands for 'end-to-end connection identifier'. It provides a means of correlating narrowband telephony connections with underlying ATM bearer connections. In the Q.BICC/ISUP+ context, the eecid is synonymous with the bnc-id (backbone network connection identifier). In the SDP session description, the more general term 'eecid' is used in order to provide a common SDP baseline for ATM telephony applications using Q.BICC/ISUP+ and SIP/SIP+. * The 'profiledesc' attribute which can be used to describe AAL2 profiles. Although any AAL2 profile can be so described, this attribute is useful for describing, at connection establishment time, custom profiles that might not be known to the far end. This attribute applies in the AAL2 context only. * The 'vsel' attribute which, depending on the application, can indicate preference for or selection of a single voice codec. This can be optionally used in both the AAL1 and AAL2 contexts in conjunction with the 'm' line. * The 'dsel' attribute which, depending on the application, can indicate preference or selection of a single voiceband data codec. This can be optionally used in both the AAL1 and AAL2 contexts in conjunction with the 'm' line. * The 'fsel' attribute which, depending on the application, can indicate preference or selection of a single fax codec. This can be optionally used in both the AAL1 and AAL2 contexts in conjunction with the 'm' line. * The 'qosclass' attribute which indicates the QoS class of the ATM bearer connection. * The 'qosparms' attribute which can be used to describe certain key QoS parameters (called Extended QoS parameters in UNI 4.0 and PNNI). * The 'gnrltrfcdesc' attribute which can be used to describe certain general traffic parameters. * The 'atmtrfcdesc' attribute which can be used to describe certain key ATM traffic parameters. Rajesh Kumar, Mohamed Mostafa [Page 12] 5.7.1 The 'atmmap' attribute The 'atmmap' attribute is defined on the basis of the 'rtpmap' attribute used in RFC2327. a=atmmap: The 'atmmap' attribute is used to dynamically map encoding names into payload types. This is necessary for those encoding names which have not been assigned a static payload type through IANA. Payload types and encoding techniques that have been registered with IANA for RTP are retained for AAL1-based narrowband telephony. The encoding names in Table 1 are case-insensitive. Table 1: Encoding Names and Payload Types |---------------------|--------------|---------------------------| | Encoding Technique | Encoding Name| Payload type | |---------------------|--------------|---------------------------| | PCM - Mu law | "PCMU" | 0 (Statically Mapped) | |---------------------|--------------|---------------------------| | 32 kbps ADPCM | "G726-32" | 2 (Statically Mapped) | |---------------------|--------------|---------------------------| |Dual rate 5.3/6.3kbps| "G723" | 4 (Statically Mapped) | |---------------------|--------------|---------------------------| | PCM- A law | "PCMA" | 8 (Statically Mapped) | |---------------------|--------------|---------------------------| | 7 KHz audio coding | "G722" | 9 (Statically Mapped) | | within 64 kbps | | | |---------------------|--------------|---------------------------| | LD-CELP | "G728" | 15 (Statically Mapped) | |---------------------|--------------|---------------------------| | CS-ACELP | "G729" | 18 (Statically Mapped) | |(normal/low-complexity) | | |---------------------|--------------|---------------------------| | Low-complexity | "X-G729a" | None, map dynamically | | CS-ACELP | | | |---------------------|--------------|---------------------------| |Normal | "X-G729b" | None, map dynamically | |CS-ACELP w/ ITU | | | |defined silence | | | |suppression | | | |---------------------|--------------|---------------------------| |Low-complexity | "X-G729ab" | None, map dynamically | |CS-ACELP w/ ITU | | | |defined silence | | | |suppression | | | |---------------------|--------------|---------------------------| | 16 kbps ADPCM | "X-G726-16" | None, map dynamically | |---------------------|--------------|---------------------------| | 24 kbps ADPCM | "X-G726-24" | None, map dynamically | |---------------------|--------------|---------------------------| | 40 kbps ADPCM | "X-G726-40" | None, map dynamically | |---------------------|--------------|---------------------------| Rajesh Kumar, Mohamed Mostafa [Page 13] Table 1 (continued): Encoding Names and Payload Types |---------------------|--------------|---------------------------| | Encoding Technique | Encoding Name| Payload type | |---------------------|--------------|---------------------------| | Dual rate 5.3/6.3 |"X-G7231-H" | None, map dynamically | | kbps - high rate | | | |---------------------|--------------|---------------------------| | Dual rate 5.3/6.3 |"X-G7231-L" | None, map dynamically | | kbps - low rate | | | |---------------------|--------------|---------------------------| | Dual rate 5.3/6.3 |"X-G7231a-H" | None, map dynamically | | kbps - high rate w/ | | | | ITU-defined silence | | | | suppression | | | |---------------------|--------------|---------------------------| | Dual rate 5.3/6.3 |"X-G7231a-L" | None, map dynamically | | kbps - high rate w/ | | | | ITU-defined silence | | | | suppression | | | |---------------------|--------------|---------------------------| | 16 kbps EADPCM | "X-G729a" | None, map dynamically | | (2 bits/sample) | | | |---------------------|--------------|---------------------------| |Normal | "X-G729b" | None, map dynamically | |CS-ACELP w/ ITU | | | |defined silence | | | |suppression | | | |---------------------|--------------|---------------------------| |Low-complexity | "X-G729ab" | None, map dynamically | |CS-ACELP w/ ITU | | | |defined silence | | | |suppression | | | |---------------------|--------------|---------------------------| | 16 kbps ADPCM | "X-G726-16" | None, map dynamically | |---------------------|--------------|---------------------------| | 24 kbps ADPCM | "X-G726-24" | None, map dynamically | |---------------------|--------------|---------------------------| | 32 kbps ADPCM | "X-G726-32" | None, map dynamically | |---------------------|--------------|---------------------------| | 40 kbps ADPCM | "X-G726-40" | None, map dynamically | |---------------------|--------------|---------------------------| |n x 64 kbps Clear | "X-CCD" | None, map dynamically | |Channel without CAS | | | |per af-vtoa-78. | | | |---------------------|--------------|---------------------------| |n x 64 kbps Clear | "X-CCD-CAS" | None, map dynamically | |Channel with CAS | | | |per af-vtoa-78. | | | |---------------------|--------------|---------------------------| |GSM Full Rate | "GSM" | 3 (Statically Mapped) | |---------------------|--------------|---------------------------| |GSM Half Rate | "X-GSM-HR" | None, map dynamically | |---------------------|--------------|---------------------------| |GSM-Enhanced Full Rate "X-GSM-EFR" | None, map dynamically | |---------------------|--------------|---------------------------| |GSM-Enhanced Half Rate "X-GSM-EHR" | None, map dynamically | |---------------------|--------------|---------------------------| Rajesh Kumar, Mohamed Mostafa [Page 14] 5.7.2 The 'eecid' attribute The 'eecid' attribute is synonymous with the 4-byte'bnc-id' parameter defined by T1SI, the ATM forum and the ITU Q.BICC standardization effort. The term 'eecid' stands for 'end-to-end connection identifier', while 'bnc-id' stands for 'backbone network connection identifier'. The name "backbone" is slightly misleading since it refers to the entire ATM network including the ATM edge and ATM core networks. In Q.BICC terminology, an ATM "backbone" connects TDM or analog edges. While the term 'bnc-id' might be used in the bearer signaling plane and in an ISUP+/BICC call control plane, SDP session descriptors use the neutral term 'eecid'. This provides a common SDP baseline for applications that use ISUP+/BICC and applications that use SIP/SIP+. In the forward SVC establishment model, the call-originating gateway initiates SVC establishment and transmits an eecid to the call- terminating gateway via SDP. In backward SVC establishment model, the call-originating gateway does not initiate SVC establishment. However, it transmits an eecid to the call-terminating gateway via SDP. The call-terminating gateway initiates SVC establishment. The value of the eecid attribute values needs to be unique within the gateway initiating the SVC set-up but not across multiple gateways. Hence, the SVC-initiating gateway has complete control over using and releasing values of this parameter. The eecid attribute is used to correlate, one-to-one, received SVC SETUP requests with service connection requests from the call agent. In the forward call model, the call-terminating gateway uses the ATM address of the call-originating gateway in the 'c' line of the session description to qualify the eecid. This is because multiple call-originating gateways can sending identical eecids. Within an SDP session description, the eecid attribute is used as follows: a=eecid: where consists of up to 8 hex digits (equivalent to 4 octets). The SVC-initiating gateway tunnels the eecid value through a Q.2931 (UNI, PNNI, AINI, IISP, proprietary Q.2931 equivalent ) set- up message or the Q.2630.1 Establish Request (ERQ) message. Rajesh Kumar, Mohamed Mostafa [Page 15] For Q.2931, the following viable options exist for tunneling the eecid through bearer-plane signaling messages: * Use the Generic Identifier Transport (GIT) IE. This method is being standardized by the ATM forum for carriage of the 'bnc-id' ('eecid'). * Use the called party subaddress IE in the backward SVC call establishment model. Use the calling party subaddress IE in the forward SVC call establishment model. Several other non-viable options such as using the NSAP selector byte are not described here. For Q.2630.1, the SUGR (Served User Generated Reference) IE can be used (subject to finalization of the standard). In the backward path set-up model, the call-originating gateway can release and re-use an eecid when it receives Q.2931 set-up or Q.2630.1 establish request from the call-terminating end. As described above, the 'eecid' is tunneled through this Q.2931 or Q.2630.1 message. In the forward path set-up model, the call-originating gateway can release and re-use an eecid when it receives a Q.2931 connect or Q.2630.1 establish confirm from the call-terminating end. This message need not carry the eecid. The Q.2931 call reference or the Q.2630.1 Destination Signaling Association Identifier (DSAID) points to the eecid. Since the gateway that issued the in the SDP 'owns' it, there can be no race conditions in re-using its value immediately on release. If not already released by the gateway issuing it, the value is released by the issuing gateway if the connection is deleted or the connection set-up aborted. 5.7.3 The 'profiledesc' attribute There is one 'profiledesc' media attribute line for each AAL2 profile that is intended to be described. The 'profiledesc' media attribute line is structured as follows: a=profiledesc: ... Here, and are identical to their definition, above, for the 'm' line. The profile elements (rows in the profile tables of ITU I.366.2 or AF-VTOA-0113) are represented as four-tuples following the parameter in the 'profiledesc' media attribute line. If a member of one of these four-tuples is not specified or is implied, then it is set to '-'. The parameter is represented by D1-D2, where D1 and D2 are decimal integers in the range 0 through 15. Rajesh Kumar, Mohamed Mostafa [Page 16] The parameter can take one of the values in column 2 of Table 1. Additionally, it can take on the following descriptor strings: "PCMG", "SIDG" and "SID729". These stand for generic PCM, generic SID and G.729 SID respectively. The is a decimal integer representation of the AAL2 packet length in octets. The is a decimal integer representation of the AAL2 packetization interval in ms. For instance, the 'profiledesc' media attribute line below defines the AAL2/custom 100 profile. This profile is reproduced in the table below. For a description of the parameters in this profile such as M and the sequence number interval, see ITU I.366.2. a=profiledesc:AAL2/custom 100 0-7 PCMG 40 5 0-7 SIDG 1 5 8-15 G726-32 40 10 8-15 SIDG 1 5 If the parameter is to be omitted or implied, then the same profile can be represented as follows: a=profiledesc:AAL2/custom 100 0-7 PCMG 40 - 0-7 SIDG 1 - 8-15 G726-32 40 - 8-15 SIDG 1 - If a gateway has a provisioned or hard coded definition of a profile, then any definition provided via the 'profiledesc' line overrides it. The exception to this rule is with regard to standard profiles such as ITU-defined profiles and ATMF-defined profiles. In general, these should not be defined via a 'profiledesc' media attribute line. If they are, then the definition needs to be consistent with the standard definition else the SDP session descriptor should be rejected with an appropriate error code. |---------------------------------------------------------------| | UUI | Packet |Encoding | | |Packet|Seq.No. | | Code | Length |per ITU |Description of | M |Time |Interval| |point |(octets)|I.366.2 | Algorithm | |(ms) |(ms) | |Range | | 2/99 | | | | | | | | version | | | | | |---------------------------------------------------------------| | 0-7 | 40 | Figure | PCM, G.711-64,| 1 | 5 | 5 | | | | B-1 | generic | | | | |------|--------|---------|---------------|-----|------|--------| | 0-7 | 1 | Figure | Generic SID | 1 | 5 | 5 | | | | I-1 | | | | | |------|--------|---------|---------------|-----|------|--------| | 8-15 | 40 | Figure | ADPCM, | 2 | 10 | 5 | | | | E-2 | G.726-32 | | | | |------|--------|---------|---------------|-----|------|--------| | 8-15 | 1 | Figure | Generic SID | 1 | 5 | 5 | | | | I-1 | | | | | |------|--------|---------|---------------|-----|------|--------| Rajesh Kumar, Mohamed Mostafa [Page 17] 5.7.4 The 'vsel' attribute The 'vsel' media attribute line can be used to indicate either preference for or selection of a single voice codec in ATM-based narrowband telephony applications. When present, it complements the media information 'm' line. The 'vsel' line is structured as follows: a=vsel: where the parameter can take one of the values in column 2 of Table 1. The and parameters are per their definition, above, for the 'profiledesc' media attribute line. Each of these parameters (, and ) can be set to '-' when not needed. Also, the entire 'vsel' media attribute line can be omitted when not needed. For example, a=vsel:G729 10 10 indicates preference for or selection of G.729 or G.729a (both are interoperable) as the voice encoding scheme. A packet length of 10 octets and a packetization interval of 10 ms are indicated in this media attribute line. If the packet length and packetization interval are intended to be omitted, then this media attribute line becomes a=vsel:G729 - - The media attribute line a=vsel:G726-32 40 10 indicates preference for or selection of 32 kbps ADPCM with a packet length of 40 octets and a packetization interval of 10 ms. 5.7.5 The 'dsel' attribute The 'dsel' media attribute line can be used to indicate either preference for or selection of a single voiceband data codec in ATM-based narrowband telephony applications. If an 'fsel' media attribute line is not present in the SDP session descriptor, then 'dsel' applies to both modem data and fax data (unless the latter is well-known by default). If an 'fsel' media attribute line is indeed present in the same SDP session description, then 'dsel' applies to modem data but not to fax data. When present, 'dsel' complements the media information 'm' line. The 'dsel' line is structured as follows: a=dsel: where the parameter can take one of the values in column 2 of Table 1. The and parameters are per their definition, above, for the 'profiledesc' media attribute line. Each of these parameters (, and ) can be set to '-' when not needed. Also, the entire 'dsel' media attribute line can be omitted when not needed. Rajesh Kumar, Mohamed Mostafa [Page 18] For example, a=dsel:G726-32 20 5 indicates preference for or selection of 32 kbps ADPCM with a packet length of 20 octets and a packetization interval of 5 ms as the voiceband data encoding scheme. 5.7.6 The 'fsel' attribute The 'fsel' media attribute line can be used to indicate either preference for or selection of a single fax data codec in ATM-based narrowband telephony applications. If an 'fsel' media attribute line is not present in the SDP session descriptor, then 'dsel' applies to both modem data and fax data (unless the latter is well- known by default). When present, 'fsel' complements the media information 'm' line. The 'fsel' line is structured as follows: a=fsel: where the parameter can take one of the values in column 2 of Table 1. The and parameters are per their definition, above, for the 'profiledesc' media attribute line. Each of these parameters (, and ) can be set to '-' when not needed. Also, the entire 'fsel' media attribute line can be omitted when not needed. For example, a=fsel:FXDMOD-3 - - indicates demodulation and remodulation of ITU-T group 3 fax at the gateway. 5.7.7 The 'qosclass' attribute When present, the 'qosclass' attribute indicates one QoS class specified by the entity constructing the SDP session description. The 'qosclass' media attribute line is structured as follows: a=qosclass: Here, is a string that is understood by all entities which parse or build the SDP descriptor. Possible values of this parameter are per the ATMF forum af-tm-0056.000 definition ('cbr', 'rt-vbr', 'nrt-vbr', 'abr', 'ubr' and 'gfr') or the ITU I.371 definition ('sbr1', 'sbr2', 'sbr3', 'dbr', 'abt/dt', 'abt/it' and 'abr'). These string values are case-insensitive. When the bearer connection is a single CID within a multiplexed AAL2 VC, then this SDP attribute does not apply. Rajesh Kumar, Mohamed Mostafa [Page 19] 5.7.8 The 'qosparms' attribute When present, the 'qosparms' attribute can be used to describe certain key QoS parameters (called Extended QoS parameters in UNI 4.0 and PNNI). In this context, these parameters can refer to acceptable values (worst case) and can be used by the bearer signaling and routing protocols. The 'qosparms' media attribute line is structured as follows: a=qosparms: The parameter indicates the base unit used for the remaining parameters in the 'qosparms' media attribute line. In the 'qosparms' media attribute line, it can take on the values 'p' or 'c'. A value of 'p' indicates that the remainder of the 'qosparms' media attribute line refers to packet latency, jitter and loss ratio. An example of such a packet stream is an AAL2 packet stream referenced by a CID value. A value of 'c' indicates that the remainder of the 'qosparms' media attribute line refers to cell latency, jitter and loss ratio. and refer to the forward and backward jitter in microseconds. As qualified by , this can be packet jitter or cell jitter. It is probably adequate to express it as a decimal integer, although fractional values are not excluded. and refer to the forward and backward latency in microseconds. As qualified by , this can be packet latency or cell latency. It is probably adequate to express it as a decimal integer, although fractional values are not excluded. and refer to forward and backward loss ratios. As qualified by , this can be packet loss ratio or cell loss ratio. The ratio referred to is between the number of units (packets/cells) lost and the number of units transmitted. It is expressed as an order of magnitude n, where the loss ratio takes on the value 10 to the minus n. The value of n is coded as a decimal integer. Within the 'qosparms' media attribute line, forward (f) refers to the direction from the entity initiating Bearer signaling (Q.2931- based or Q.2630.1-based). Backward (b) refers to the opposite direction. If any of these parameters is not specified, inapplicable or is implied, then it is set to '-'. An example use of the attribute for an rt-VBR, single- CID AAL2 voice VC is: a=qosparms:c 8125 32000 11 4675 18000 12 Rajesh Kumar, Mohamed Mostafa [Page 20] This implies a forward path cell delay variation of 8.125 ms, a backward path cell delay variation of 4.675 ms, a forward path latency of 32 ms, a backward path latency of 18 ms, a forward path cell loss ratio of 10 to the minus 11 and a backward path cell loss ratio of 10 to the minus 12. 5.7.9 The 'gnrltrfcdesc' attribute When present, the 'gnrltrfcdesc' attribute can be used to indicate traffic rates and maximum burst sizes. The 'gnrltrfcdesc' media attribute line is structured as follows: a=gnrltrfcdesc: The parameter indicates the base unit used for the remaining parameters in the 'gnrltrfcdesc' media attribute line. In the 'gnrltrfcdesc' media attribute line, it can take on the values 'p', 'c', 'b' and 'o'. A value of 'p' indicates that packets per second and packets are used respectively as the units for rates and burst sizes in the remainder of the 'gnrltrfcdesc' media attribute line. A value of 'c' indicates that cells per second and cells are used respectively as the units for rates and burst sizes in the remainder of the 'gnrltrfcdesc' media attribute line. A value of 'b' indicates that bits per second and bits are used respectively as the units for rates and burst sizes in the remainder of the 'gnrltrfcdesc' media attribute line. A value of 'o' indicates that octets per second and octets are used respectively as the units for rates and burst sizes in the remainder of the 'gnrltrfcdesc' media attribute line. Units of packets, cells, bits or octets are applicable depending on the application context. For instance, when the underlying bearer connection is an AAL1 VC or a single-CID AAL2 VC, cells are the appropriate unit. When the underlying bearer connection is a multiplexed AAL2 VC, packets are the appropriate unit. and are the forward and backward peak rates. Depending of the value of , their units are packets per second, cells per second, bits per second or octets per second. When referring to an ATM VC, and apply to cells with CLP values of 0 or 1 within the nrt-VBR, rt-VBR and CBR QoS classes. and are the forward and backward sustainable rates. Depending of the value of , their units are packets per second, cells per second, bits per second or octets per second. When referring to an ATM VC, and apply to cells with a CLP value of 0 within the nrt-VBR and rt-VBR QoS classes. and are the forward and backward minimum rates. Depending of the value of , their units are packets per second, cells per second, bits per second or octets per second. When Rajesh Kumar, Mohamed Mostafa [Page 21] referring to an ATM VC, and apply to cells with CLP values of 0 or 1 within the ABR QoS class. and are the forward and backward maximum burst sizes. Depending of the value of , their units are packets, cells, bits or octets. When referring to an ATM VC, and apply to cells with a CLP value of 0 within the nrt-VBR and rt-VBR QoS classes. Within the 'gnrltrfcdesc' media attribute line, forward (f) refers to the direction from the entity initiating Bearer signaling (Q.2931-based or Q.2630.1-based). Backward (b) refers to the opposite direction. If any of these parameters is not specified, inapplicable or is implied, then it is set to '-'. An example use of the attribute for an rt-VBR, single-CID AAL2 voice VC is: a=gnrltrfcdesc:c 200 100 - 20 200 100 - 20 This implies a forward and backward PCR of 200 cells per second, a forward and backward SCR of 100 cells per second, an MCR that is unspecified since it is inapplicable and a forward and backward maximum burst size of 20 cells. 5.7.10 The 'atmtrfcdesc' attribute When present, the 'atmtrfcdesc' attribute can be used to indicate ATM-specific traffic parameters such as CLP tagging, frame discard and best effort indicators. The 'atmtrfcdesc' media attribute line is structured as follows: a=atmtrfcdesc: is the best effort indicator flag. It can take on the values of "on" and "off". An "on" value applies only to the UBR QoS class. and indicate that frame discard is permitted in the forward or backward directions. These can take on the values of "on" or "off". (forward tag enable) and (backward tag enable) indicate that CLP tagging is requested in the forward or backward directions. These can take on the values of "on" or "off". In these parameters, forward (f) refers to the direction from the entity initiating Bearer signaling (Q.2931-based or Q.2630.1- based). Backward (b) refers to the opposite direction. If any of these parameters is not specified or is implied, then it is set to '-'. Rajesh Kumar, Mohamed Mostafa [Page 22] An example use of the attribute for an rt-VBR, single-CID AAL2 voice VC is: a=atmtrfcdesc:- off off off off This implies that best effort is inapplicable and that frame discard and CLP tagging are disabled in the forward and backward directions. 5.8 Examples of ATM session descriptions using SDP An example of a complete AAL1 session description in SDP is: v=0 o=- A3C47F21456789F0 0 ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00 s=- c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00 t=0 0 m=audio $ AAL1/AVP 18 0 96 a=atmmap:96 G727-32 a=eecid:B3D58E32 An example of a complete AAL2 session description in SDP is: v=0 o=- A3C47F21456789F0 0 ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00 s=- c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00 t=0 0 m=audio $ AAL2/ITU 8 AAL2/custom 100 AAL2/ITU 1 a=eecid:B3E32 Rajesh Kumar, Mohamed Mostafa [Page 23] The AAL2 session descriptor below is the same as the one above except that it states an explicit preference for a voice codec, a voiceband data codec and a voiceband fax codec. Further, it defines the profile AAL2/custom 100 rather than assume that the far-end is cognizant of the elements of this profile. v=0 o=- A3C47F21456789F0 0 ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00 s=- c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00 t=0 0 m=audio $ AAL2/ITU 8 AAL2/custom 100 AAL2/ITU 1 a=eecid:B3E32 a=profiledesc:AAL2/custom 100 0-7 PCMG 40 5 0-7 SIDG 1 5 8-15 G726-32 40 10 8-15 SIDG 1 5 a=vsel:G726-32 40 10 a=dsel:PCMU - - a=fsel:G726-32 40 10 5.9 Representation of data media The following encoding names in Table 1 can refer to data as well as audio media: CCD and CCD-CAS in Table 1. The following encoding names in Table 1 refer to data media: FXDMOD-3 in Table 1. In the AAL1 context, the media information line for these media should be constructed as follows: is as defined above in this document for AAL1 sessions. 'DP' stands for 'data profile' along the lines of 'AVP' for 'audio-video profile'. specifies the number of TDM DS0s that are aggregated by this encoding. For T1-based applications, it can take on integral values in the inclusive range [1...24]. For E1-based applications, it can take on integral values in the inclusive range [1...31]. The default value is 1 and is equivalent to omitting this parameter. Setting this parameter to a '-' is equivalent to omitting it. In the AAL2 context, the media information line for these data media should be structured as follows: is as defined above in this document for AAL2 sessions. 'DP' stands for 'data profile' along the lines of 'AVP' for 'audio-video profile'. is as defined above for the AAL1 context. Rajesh Kumar, Mohamed Mostafa [Page 24] Note that there is only one encoding technique specified in the media information line. This is because: * In the case of n x 64 kbps clear channel data, there only one encoding and packetization format given a particular 'n' and a particular adaptation (AAL1/AAL2). * In the case of fax demodulation and remodulation (ITU I.366.2), parameters such as information type, image data size and control type are negotiated in the 'bearer plane' via type 3 messages. Therefore, there is no need to define several alternate encoding techniques. Similarly, for sending fax over IP, it is likely that 'bearer plane' messages will be used to synchronize the two ends. Also, AAL1 is not likely to be used for relaying demodulated fax data and control. Examples of valid representations of data media are: m=data 29 AAL1/DP CCD 6 This indicates that VCCI=29 uses AAL1 encapsulation to transmit an nx64 clear channel with n=6. m=data 122/8 AAL2/DP CCD 12 This indicates that VCCI/CID=122/8 uses AAL2 encapsulation to transmit an nx64 clear channel with n=12. m=data 122/8 AAL2/DP FXMOD-3 '-' This indicates that VCCI/CID=122/8 uses AAL2 encapsulation to transmit group 3 demodulated facsimile and the associated control. m=data 122/8 AAL2/DP FXMOD-3 This indicates that VCCI/CID=122/8 uses AAL2 encapsulation to transmit group 3 demodulated facsimile and the associated control. Rajesh Kumar, Mohamed Mostafa [Page 25] 6.0 Security Considerations Security considerations for SDP extended for ATM are similar to those for standard SDP described in RFC2327. In general, the SDP session descriptions might originate in untrusted areas such as equipment owned by end-subscribers or located at end-subscriber premises. SDP relies on the security mechanisms of the encapsulating protocol or layers below the encapsulating protocol. Examples of encapsulating protocols are the Session Initiation Protocol (SIP) and the Multimedia Gateway Control Protocol (MEGACO). These protocols can use IPSec authentication as described in RFC1826 [Ref. 27]. IPSec encryption can be optionally used with authentication to provide an additional, potentially more expensive level of security. IPSec security associations can be made between equipment located in untrusted areas and equipment located in trusted areas through configured shared secrets or the use of a certificate authority. References [1] IETF RFC 2327, 'SDP: Session Description Protocol', April '98, Mark Handley and Van Jacobson. [2] IETF RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications', Jan. 1996. [3] IETF RFC 1890, 'RTP Profile for Audio and Video Conferences with Minimal Control', Jan. 1996. [4] ATMF UNI 3.1 Specification, af-uni-0010.002. Of special interest for this document is Section 5.4.5.5, ATM Adaptation Layer Parameters. [5] ATMF UNI 4.0 Specification, af-sig-0061.000. [6] ATMF Traffic Management Specification, Version 4.0, af-tm- 0056.000. [7] ATMF Circuit Emulation Service (CES) Interoperability Specification, version 2.0, af-vtoa-0078.000, Jan. 97. [8] ATMF Voice and Telephony over ATM û ATM Trunking using AAL1 for Narrowband Services, version 1.0, af-vtoa-0089.000, July 1997. [9] ATMF Specifications of (DBCES) Dynamic Bandwidth Utilization û in 64kbps Timeslot Trunking over ATM - using CES, af-vtoa- 0085.000, July 1997. [10] ITU-T I.363.1, B-ISDN ATM Adaptation Layer Specification: Type 1 AAL, August 1996. Rajesh Kumar, Mohamed Mostafa [Page 26] [11] ITU-T I.363.2, B-ISDN ATM Adaptation Layer Specification: Type 2 AAL, Sept. 1997. [12] ITU-T I.366.1, Segmentation and Reassembly Service Specific Convergence Sublayer for AAL Type 2, June 1998. [13] ITU-T I.366.2, AAL Type 2 Reassembly Service Specific Convergence Sublayer for Trunking, Feb. 99. [14] Draft ietf-avt-telephone-tones-05.txt, RTP payloads for Telephone Signal Events, S.B.Petrack, Nov. 17, 1998. [15] ITU-T Q.2931, B-ISDN Application Protocol for Access Signaling. [16] Amendment 2 to ITU-T Q.2931, B-ISDN Application Protocol for Access Signaling. [17] SAP: Session Announcement Protocol , draft-ietf-mmusic-sap-v2- 04.txt, Mark Handley, Colin Perkins and Edmund Whelan . [18] rfc2543, Handley, M., H. Schulzrinne , Schooler, E. and Rosenberg, J., "Session Initiation Protocol (SIP)", March 1999. [19] rfc1349, Type of Service in the Internet Protocol Suite. P. Almquist. July 1992. [20] rfc2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. K. Nichols, S. Blake, F. Baker, D. Black. December 1998. [21] ITU-T I.363.5, B-ISDN ATM Adaptation Layer Specification: Type 5 AAL, Aug. 1996. [22] ATMF PNNI 1.0, af-pnni-0055.000, March 1996. [23] ietf-avt-rtp-new-05.txt, Oct. 21, 1999, RTP: A Transport Protocol for Real-Time Applications. [24] ietf-avt-profile-new-07.txt, Oct. 21, 1999, RTP Profile for Audio and Video Conferences with Minimal Control. [25] Media Gateway Control Protocol (MGCP), Mauricio Arango, Isaac Elliott, Christian Huitema, Scott Pickett, Version 1.0, RFC2705. [26] draft-ietf-megaco-reqs-10.txt, January 5, 2000, Media Gateway control protocol architecture and requirements, Nancy Greene, Michael A. Ramalho, Brian Rosen. [27] IP Authentication Header, R. Atkinson, August 1995, RFC1826. Rajesh Kumar, Mohamed Mostafa [Page 27] Acknowledgements The authors wish to thank several colleagues at Cisco and in the industry who have contributed towards the development of these SDP extensions, and who have reviewed, implemented and tested these constructs. Valuable technical ideas that have been incorporated into this internet draft have been provided by Hisham Abdelhamid, David Auerbach, Robert Biskner, Steve Casner, Alex Clemm, Bill Foster, Snehal Karia, Raghu Thirumalai Rajan, Joe Stone, Bruce Thompson and Dan Wing of Cisco, Michael Brown, Rade Gvozdanovic,Graeme Gibbs and Sophia Scoggins of Nortel Networks, and Ed Guy and Petros Mouchtaris of Telcordia. The authors also wish to thank the ISC device control group, especially Charles Eckel, Christian Groves, Tom Jepsen, Brian Rosen and Tom Taylor for their review comments and their assistance in the preparation of this document. Authors' Addresses Rajesh Kumar Cisco Systems, Inc. M/S SJC01/3 170 West Tasman Drive San Jose, CA 95134-1706 Phone: 1-800-250-4800 Email: rkumar@cisco.com Mohamed Mostafa Cisco Systems, Inc. M/S SJC01/3 170 West Tasman Drive San Jose, CA 95134-1706 Phone: 1-800-250-4800 Email: mmostafa@cisco.com Full Copyright Statement Copyright (C) The Internet Society (March 2, 2000). 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. Rajesh Kumar, Mohamed Mostafa [Page 28] 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." Rajesh Kumar, Mohamed Mostafa [Page 29]