Network Working Group Quoc Chinh Nguyen Internet Draft Misarc Network Laboratory Intended status: Standards Track Expires: June 4, 2008 December 4, 2007 V5 Level two and three Over IP Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 4, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document proposes the use TCP/IP as the transport protocol for V5. The migration from the current trunk 2048 kbps physical to an IP based transport will reduce the cost associated with dedicated trunk based link. Also, the current signaling End-to-End will be unchanged to make the transition seamless as possible. Quoc Chinh Nguyen Expires June 4, 2008 [Page 1] Internet-Draft V5 Level two and three Over IP December, 2007 Table of contents: 1. Introduction . . . . . . . . . . . . . . . . . . Page 3 2. V5 Protocol . . . . . . . . . . . . . . . . . . Page 3 2.1 Differences between V5.1 and V5.2 . . . . . . . Page 3 2.2 Protocols . . . . . . Page 3 3. IP node . . . . . . . . . . . . . . . . . . . . Page 5 4. Quasi-associated Network . . . . . . . . . . . Page 5 5. V5 Signaling and IP Connection . . . . . . . . Page 6 6. TCP encapsulation . . . . . . . . . . . . . . . Page 5 7. IP Multilink timers . . . . . . . . . . . . . . Page 7 7.1 Layer 2 ISDN protocol . . . . . . . . . . . Page 7 7.2 BCC protocol . . . . . . . . . . . . . . . Page 7 7.3 Protection protocol . . . . . . . . . . . . Page 7 8. IPMultilink procedures . . . . . . . . . . . . Page 7 8.1 IPMultilink BCC procedures . . . . . . . . Page 7 8.2 IPMultilink Protection procedures . . . . . Page 7 8.3 IPMultilink Port Alignment procedure . . . Page 8 8.3.1 Coordinated Port Alignment . . . . . . . Page 8 8.3.2 Accelerated Port Alignment procedure . Page 8 9. IPMultilink CRC-4 Multiframe . . . . . . . . . Page 8 10. IPMultilink SA7 bit . . . . . . . . . . . . . Page 8 11. IPMultilink identification . . . . . . . . . . Page 8 12. Security Considerations . . . . . . . . . . Page 8 13. IANA Considerations . . . . . . . . . . . . . Page 8 14. Acknowledgement . . . . . . . . . . . . . . Page 8 15. References . . . . . . . . . . . . . . . . . Page 9 15.1 Normative references . .. . . . . . . . . Page 9 15. Informative references . . . . . . . . . . Page 9 Quoc Chinh Nguyen Expires June 4, 2008 [Page 2] Internet-Draft V5 Level two and three Over IP December, 2007 1. Introduction This draft defines the encapsulation of V5 messages in TCP/UDP packets. The concept of a physical link will be maintained, which will emulate the V5 links. 2. V5 Protocol The V5 protocol stack is used for the connection of an Access Network (AN)to a Local Exchange (LE).The AN is a system between the LE and the user, replacing part or whole of the local line distribution network. It is used for the following access method: - PSTN telephone access. - ISDN basic rate access. - ISDN primary rate access (V5.2). There are two forms of V5: V5.1 and V5.2. The V5.1 protocol operates on single E1 circuit, while the V5.2 protocol operates on a group of E1 circuits(up to 16 E1 lines). Both of these interfaces may utilize time slots 15,16,and 31 for signaling. Time slot zero(TS0) of the 32 time slots is always used for frame alignment, error reporting and error monitoring using cyclic redundancy check procedures. In the cases of V5.2 links, TS0 is additionally used to verify the correct physical connection of 2048 kbps. 2.1 Differences between V5.1 and V5.2: The major differences between V5.1 and V5.2 interface are: - The V5.1 uses only one 2048 kbit/s link, whereas V5.2 may use N(N=1-16) 2048 kbits/s on one interface. - V5.1 does not support concentration, whereas is inherently designed to support it using a dedicated protocol as the Bearer Channel Connection (BCC) protocol. - V5.1 does not support ISDN primary rate access user ports, whereas V5.2 does. Furthermore, the ISDN primary rate access shall be applicable in semi-permanent leased line and permanent line as well as direct user ports. - V5.1 has no concept of communication channel protection, whereas this function is available for V5.2 when that particular V5.2 interface uses more than one 2048 kbit/s. A specific protocol, known as the protection protocol, is provided for this function. 2.2 Protocols The following protocols are defined for the various protocol layers: Layer 2: - LAPV5-EF The V5 Envelope Function sublayer exchanges information between the AN and the LE. Quoc Chinh Nguyen Expires June 4, 2008 [Page 3] Internet-Draft V5 Level two and three Over IP December, 2007 - LAPV5-DL The LAPV5 Data Link sublayer defines peer-to-peer exchanges of information between the AN and the LE. LAPV5-DL frames can be either with or without an information filed. Layer 3: - V5-Link Control The V5 Link Control Protocol is sent by the AN or the LE to convey information required for the coordination of the link control functions for each individual 2048 kbps link. - V5-BCC The V5-BCC protocol provides the means for the LE to request the AN to establish and release connections between specified AN user ports and specified V5 interface time slots. It enables V5 interface bearer channels to be allocated or de-allocated by independent processes. There may be more than one process active at any one time for given user port. - V5-PSTN The Public Switched Telephone Network (PSTN)protocol defines a lot of useful messages for call initiation and progress in both directions. This protocol sets up and clears down connections, and carries the information on the condition of the time that can be used for necessary analogue call. The V5-PSTN protocol is used in conjunction with the national protocol entity in the LE. The national protocol entity in the LE, which is used for customer lines which are connected directly to the LE, is also used to control calls on customers lines which are connected via the V5-interface. The majority of the line signals are not interpreted by the V5-PSTN protocol, but simply transferred transparently between the user port in the AN and the national protocol entity in the LE. User Port V5 AN side V5 LE side nat. PSTN protocol | | | | idle | FE-sub_seiz | Establish | FE-establish_ind | off- | ------------->| ----------------->| ---------------->| hook | | Ss = off hook | (off hook ) | | | | | | | Establish Ack | FE-establish_ack | | |<----------------- |<---------------- | | | | | | | dial tone | | dial- |<------------- | ----------------- | ---------------- | tone | | | | <-----------------> V5 AN PSTN protocol entity Quoc Chinh Nguyen Expires June 4, 2008 [Page 4] Internet-Draft V5 Level two and three Over IP December, 2007 - V5-CONTROL Control protocol contains two parts: User Port Control and Common Control. The Port Control performs the blocking and unblocking functions of the individual ports, when faults occur or for maintenance purposes. In addition, it also supports functions that are specific to ISDN ports only, such as activation and deactivation, fault and performance indications, and flow control for signaling ISDN ports. The Common Control protocols is responsible for checking the identity of the V5 interface, to ensure interconnection accuracy and the consistency in the configuration of both sides of the interface. Each side of the interface can inform or request the other side of its interface ID and configuration. - V5-PROTECTION The protection protocol is used in the case of interfaces with more than one 2048 kbps link. It is required the link control, the control, and the BCC protocols have a communication path over the V5.2 interface, even in the event 2048 kbps link failure (i.e. primary or secondary link). The protection protocol has the responsibility to ensure that there is a method by which entities in the LE and AN can communicate for the purpose of protecting logical C-channels in the case of a single link failure. In the event of protection switching being required for logical C-channels, it is the responsibility of the protection management function to initiate the switch-over in a controlled manner using the protection protocol. These two time slot (time slot 16 of primary and secondary link), are considered as Protection Group 1. The protection protocol in time slot 16 of the secondary link monitors time slot 16 on both the primary and secondary links. This ensures that degradation on the primary link is detected and that the availability of the secondary link is ensured. 3. IP node The scope of IP node, in this Recommendation includes the following: - A link will be identified by an IP address and time slots 15,16, 31 may be utilized for signaling - The link alignment procedure as the control of CRC-4 Multiframe - The emergency link alignment procedure - The link Basic Error Rate (BER) monitor - The SA7 bit control. 4. Quasi-associated Network A quasi-associated network between a AN (Access Network) and LE (Local Network) is shown below. ------------- -------------- | AN | ------------- | LE | | V5.1,V5.2 | <-> | IP Network| <-> | V5.1, V5.2 | ------------- ------------- -------------- Quoc Chinh Nguyen Expires June 4, 2008 [Page 5] Internet-Draft V5 Level two and three Over IP December, 2007 Currently, the V5 messages of signaling traverse from AN through IP Network to LE using trunk E1 2048kbps. The IP network could be used As a physical alternation to E1 trunk and it must be able to Demonstrate at least equal reliabilities and non alternate the routing capabilities. 5. V5 Signaling and IP Connection Each link will have its own IP address and processor, one link 2048 kbit/s for V5.1 and could be 16 links 2048 kbit/s for V5.2. This will maintain the current link concepts intact for reliability, redundancy, alignment, load sharing, etc. V5 <-> IP <-> LE interworking should be as transparent as possible. 6. TCP encapsulation The current V5 (V5.1 or V5.2) is to be used as is. It transports the signals of analogue telephone, the messages of ISDN (BRI for V5.1 and BRI, PRI for V5.2). TCP packets will be used to transport the messages of level 2 and level 3 of V5. - TCP encapsulation of level 2 - TCP encapsulation of level 3 This mechanism reduces the risk of V5-IP-V5 losing the important information by eliminating the need for new protocols. ------------------------------- | TCP header | V5.1 or V5.2 | ------------------------------- However the type of encapsulation scheme and how it is used can have an effect on the data throughput rate and so it should not be ignored. A message can have two modes of encapsulation: framed and transparent. In transparent mode all the data from an incoming signal including interpacket gap and the preamble will be transported. This means that line-side bandwidth is being used to transport "overhead" data. Conversely if message is operated in framed mode, it will only transport the actual frame and not the preamble or interpacket gap This can obviously lead to bandwidth efficiencies. Quoc Chinh Nguyen Expires June 4, 2008 [Page 6] Internet-Draft V5 Level two and three Over IP December, 2007 7. IPMultilink Timers The timers for IPMultilink have been extended as following: 7.1 Layer 2 ISDN protocol: - T200 1 s transmission of a frame may be initiated - T203 10 s the maximum time allowed without frame being exchanged. 7.2 BCC protocol: - Tbcc1 500-1500 ms ALLOCATION sent - Tbcc2 2 s DE-ALLOCATION sent - Tbcc3 2 s DE-ALLOCATION sent - Tbcc4 500 - 1500 ms AUDIT sent - Tbcc5 500 - 1500 ms AN FAULT sent 7.3 Protection protocol: - TS01 1500 ms SWITCH-OVER Com sent - TS02 1500 ms OS-SWITCH-OVER sent - TS03 1500 ms SWITCH-OVER REQUEST sent - TS04 20 s RESET SN COM sent - TS05 10 s Receipt of RESET SN COM 8. IPMultilink Procedures Independently the choice of encapsulation, all procedures of V5 are applicable. 8.1 IPMultilink BCC procedures: - bearer channel allocation: normal procedure - bearer channel allocation: exceptional procedure - bearer channel de-allocation: normal procedure - bearer channel de-allocation: exceptional procedure - audit procedure - AN internal failure notification procedure - Handling of error conditions. are unchanged from the current procedures. 8.2 IPMultilink Protection procedures: - transmission of protection messages - receipt of protection protocol messages - sequence number reset: normal procedure - sequence number reset : exceptional procedure - standard protection switch-over procedure initiated by LE-side: normal procedure - standard protection switch-over procedure initiated by LE-side: exceptional procedure are unchanged from the current procedures. Quoc Chinh Nguyen Expires June 4, 2008 [Page 7] Internet-Draft V5 Level two and three Over IP December, 2007 8.3 IPMultilink Port Alignment procedure The Port alignment can be carried out in two ways: 8.3.1 Coordinated Port Alignment This procedure allows alignment of port states by issuing Block and Unblock messages for each individual port. This procedure is unchanged from the current procedure. 8.3.2 Accelerated Port Alignment procedure This procedure allows alignment of port states without issuing Block and Unblock messages for each individual port. This procedure is unchanged from the current procedure. 9. IPMultilink CRC-4 Multiframe E1 framing for both V5.1 and V5.2 links should always be CRC-4 Multiframe. This same reliability must be used in IPMultilink. 10. IPMultilink SA7 bit This procedure allows the verification of link continuity by link identification. This procedure is unchanged from the current procedure. 11. IPMultilink identification The IPMultilink is identified by an IP address. The required number of IP address is dependent to the AN which has the V5.1 interface or V5.2 interface. 12. Security Considerations This type of process document does not have a direct impact on the Security of the Internet or Internet protocols. 13. IANA Considerations No IANA actions are required by this document. 14. Acknowledgement The author would like to thank Franco Conti, Quang Vinh Nguyen, Giambattista Spinelli, Giovanni Stabelini for their valuable comments and suggestions. Quoc Chinh Nguyen Expires June 4, 2008 [Page 8] Internet-Draft V5 Level two and three Over IP December, 2007 15. References 15.1 Normative references International Telecommunication Union (ITU): G.964: V-Interfaces at the Digital Local Exchange (LE); V5.1 Interface based on 2048 kbps for the support of Access Network (AN) G.965: V-Interfaces at the Digital Local Exchange (LE); V5.2 Interface based on 2048 kbps for the support of Access Network (AN) Q.920: Digital Subscriber Signaling System No.1 (DSS1); User-Network Interface Data; Link Layer; General Aspects. European Telecommunication Standard (ETS): ETS 300 125 Integrated Services Digital Network (ISDN); User-network interface data link layer specification Application of CCITT Recommendations Q.920/I.440 and Q.921/I.441. ETS 300 102-1 Integrated Services Digital Network (ISDN); User-network interface layer 3 Specifications for basic call control ETS 300 324-1 Signaling Protocols and Switching (SPS); V interfaces at the digital Local Exchange (LE); V5.1 interface for the support of Access Network(AN) Part 1: V5.1 interface specification. ETS 300 347-1 V interfaces at the digital Local Exchange (LE); V5.1 interface for the support of Access Network(AN) Part 2: V5.2 interface specification. ETR 150: Signaling Protocols and Switching (SPS); V5 interface Public Switched Telephone Network (PSTN) mappings. 15.2 Informative references Reference For Comment (RFC): RFC 768 : " User Datagram Protocol (UDP)", Poster, J., August 1980. RFC 791 : " Internet Protocol (IP)", Poster, J., September, 1981 RFC 793 : " Transmission Control Protocol (TCP)", Poster, J., Septembre, 1981. RFC 768 : " User Datagram Protocol (UDP)", Poster, J., August, 1980 RFC 2119 : " Keys Words in RFCs to indicate requirement levels", Bradnex, S., March 1997. RFC 2822 : "Internet Message Format", Resnick, P., May 2001. RFC 3807: " V5.2-User Adaptation Layer (V5UA)" E. Weilandt, N. Khanchandani, S. Rao, February 2001. RFC 1889 : " RTP: A Transport Protocol for Real-Time Application", Schulzrine, H., Casner, S., Frederick, R. and V. Jacobson, January 1996. I-D Guidelines: " Guidelines to Authors of Internet Drafts" B. Fenner (for the IESG), AT&T Labs - Research, October 13, 2006. Quoc Chinh Nguyen Expires June 4, 2008 [Page 9] Internet-Draft V5 Level two and three Over IP December, 2007 Author's Address Quoc Chinh Nguyen Micro System Architecturing srl Misarc Lab. Communication and Switching Network Via della Tecnica 8/P 20041- Agrate Brianza - Milano Italy Email: chinh.nguyen@misarc.com Quoc Chinh Nguyen Expires June 4, 2008 [Page 10] Internet-Draft V5 Level two and three Over IP December, 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Quoc Chinh Nguyen Expires June 4, 2008 [Page 11]