INTERNET-DRAFT J. Loughney Internet Engineering Task Force Nokia SIGTRAN Working Group Issued: 16 June 2000 Expires: 16 December 2000 IP based Signaling Needs in Radio Access Networks 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 In developing IP-based Radio Access Networks, there are needs for reliable signaling. It is assumed that SCTP would provide the transport bearer for any signaling. This draft presents a general signaling architecture for IP-based Radio Access Networks. Internet Draft IP based Signaling Needs in RANs June 16, 2000 1. Introduction.......................................................3 1.1 Scope ............................................................3 1.2 Terminology ......................................................3 2 Architectural Framework..............................................4 2.1 Signaling Transport Architecture .................................4 2.2 Generalized Point-to-Point Network Architecture ..................4 3 Protocol Needs and Procedures........................................5 3.1 xUA Functions ....................................................5 3.2 Addressing .......................................................5 3.3 Layer 2 Impacts ..................................................6 4 Security.............................................................6 4.1 Introduction .....................................................6 4.2 SCTP Security Mechanisms .........................................6 4.4 Protecting Confidentiality .......................................6 5 Acknowledgements.....................................................6 6 Author's Addresses...................................................6 7 References...........................................................7 Loughney [Page 2] Internet Draft IP based Signaling Needs in RANs June 16, 2000 1. Introduction As the wireless Internet is developed, there is increasing interaction between the wireless and cellular world and the Internet. Traditional mobile telephony services may deployed with IP technologies such as IP- Telephony and Mobile IP. In developing IP-based solutions, radio access signaling will need to be addressed. This document presents a protocol architecture to support signaling within RANs and discusses some issues needed. 1.1 Scope Radio Access Networks terminate radio bearer information and perform edge mobility. Different radio technologies require somewhat different needs for signaling to and between access nodes (such as base stations) and between other network elements. Currently, there are different IP- based RANs being developed [UTRAN Iur] [CDMA1] [RANAP]. Within the IETF, there are aspects of IP RANs addressed in several working groups, such as SigTran, PILC, ROBHC, not to mention Mobile IP. It is assumed that addressing is done on an IP level and interworking between legacy networks are not needed. QoS and routing are currently outside of the scope of this document. 1.2 Terminology Association - An association refers to an SCTP association. The association provides the transport for the delivery of signaling messages. Fail-over - The capability to re-route signaling traffic as required to an server or group servers. Host - The computing platform that the ASP process is running on. Signaling Protocol - Application level protocol which handles signaling messages between Radio Access Network elements, (e.g. - RANAP, RNSAP, NBAP). Stream - A stream refers to an SCTP stream; a uni-directional logical channel established from one SCTP endpoint to another associated SCTP endpoint, within which all user messages are delivered in-sequence except for those submitted to the un-ordered delivery service. Transport address - an address which serves as a source or destination for the unreliable packet transport service used by SCTP. In IP networks, a transport address is defined by the combination of an IP address and an SCTP port number. Note, only one SCTP port may be defined for each endpoint, but each SCTP endpoint may have multiple IP addresses. 1.3 Why SCTP Stream Control Transmission Protocol is a newly proposed transport protocol. It is a reliable datagram transfer protocol operating on top of IP. It offers the following services: Loughney [Page 3] Internet Draft IP based Signaling Needs in RANs June 16, 2000 -- acknowledged error-free non-duplicated transfer of user data, -- data segmentation to conform to discovered path MTU size, -- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, -- optional multiplexing of user messages into SCTP datagrams, and -- network-level fault tolerance through supporting of multi-homing at either or both ends of an association. -- appropriate congestion avoidance behavior. -- resistance to flooding and masquerade attacks. SCTP provides improvements over TCP such as removing head-of-line blocking within streams and improved support of streams. These features make SCTP extremely attractive for use within radio access networks, where timing controls are quite tight. SCTP also allows an improved network architecture, supporting multihomed hosts. 2 Architectural Framework In this architecture, we propose two protocol layers - xUA and SP. xUA refers to a generic user adaptation layer which supports a Signaling Protocol (SP) to be transported over SCTP. The SP can be thought of as the application being transported; xUA provides mapping to SCTP; server level reliability, failover and load sharing; session management; and address mapping. 2.1 Signaling Transport Architecture +------+ +------+ | SP | | SP | +------+ +------+ | xUA | | xUA | +------+ +------+ | SCTP | | SCTP | +------+ +------+ | IP | | IP | +------+ +------+ | | +----------------+ xUA = User Adaptation layer SP = Signaling Protocol This architecture can be used to carry a signaling protocol in an IP network. 2.2 Generalized Point-to-Point Network Architecture Figure 1 shows an example network architecture which can support robust operation and failover support. There needs to be some management resources at the AS to manage traffic. In this example, the Servers are shown residing within one logical box, with Server Elements (SE) located inside. In fact, a Server could be distributed among several hosts. In such a scenario, the host should share state as protection in the case of a failure. Additionally, in a distributed system, one SE could be registered to more than one Server. Loughney [Page 4] Internet Draft IP based Signaling Needs in RANs June 16, 2000 This draft should not restrict such systems - though such a case in not specified. *********** *Server 1 * * +-----+ * SCTP Associations * |SE 1 +-------------------+ * +-----+ * | *********** * * | *Server 3 * * +-----+ * | * +-----+ * * |SE 2 +-----------------------------------------+SE 1 | * * +-----+ * | * +-----+ * * * | * * * +-----+ * | * +-----+ * * |SE 3 | * +--------------------------+SE 2 | * * +-----+ * | | * +-----+ * *********** | | *********** | | *********** | | *********** *Server 2 * | | *Server 4 * * +-----+ * | | * +-----+ * * |SE 1 +--------------+ +---------------------+SE 1 | * * +-----+ * * +-----+ * * * * * * +-----+ * * +-----+ * * |SE 2 +-----------------------------------------+SE 2 | * * +-----+ * * +-----+ * * * *********** * +-----+ * * |SE 3 | * * +-----+ * * * *********** SE = Signaling Element Figure 1: Generalized Architecture 3 Protocol Needs and Procedures 3.1 xUA Functions The User Adaptation Protocol (xUA), should provide for handling of primitives from the upper layer signaling protocol to SCTP. xUA should have the capability to map user traffic to specific SCTP associations and streams, as is appropriate. xUA should provide for process and/or server layer reliability, load sharing and failover. 3.2 Addressing It is assumed that all nodes use hostnames / IP addresses for signaling. For interworking with legacy systems, E.164 addresses may be used with a DNS-based mapping scheme [ENUM]. Loughney [Page 5] Internet Draft IP based Signaling Needs in RANs June 16, 2000 3.3 Layer 2 Impacts To be added. 4 Security 4.1 Introduction The signaling architecture has the following security objectives: * Availability of reliable and timely user data transport. * Integrity of user data transport. * Confidentiality of user data. In addition, the network provider may wish to protect its network topology. 4.2 SCTP Security Mechanisms SCTP provides certain transport related security features, such as: * Blind Denial of Service Attacks * Flooding * Masquerade * Improper Monopolization of Services It is reasonable to expect that this any network providing signaling over IP will include an appropriate security policy framework. The "Site Security Handbook" [2196] should be consulted for guidance. If the RAN involves more than one party, it may not be reasonable to expect that all parties have implemented security in a sufficient manner. In such a case, it is recommended that IPSEC is used to ensure confidentiality of user payload. Consult [2409] for more information on configuring IPSEC services. 4.3 Address Confidentiality When using DNS, it is suggested to use DNSSEC for securing and verifying zones. 4.4 Protecting Confidentiality Particularly for mobile users, the requirement for confidentiality may include the masking of IP addresses and ports. In this case application level encryption is not sufficient; IPSEC ESP should be used instead. Regardless of which level performs the encryption, the IPSEC ISAKMP service should be used for key management. 5 Acknowledgements The author would like to thank James Kempf, Greg Sidebottom and Tom Taylor. 6 Author's Addresses John Loughney Nokia Research Center Loughney [Page 6] Internet Draft IP based Signaling Needs in RANs June 16, 2000 PO Box 407 FIN-00045 Nokia Group Finland john.loughney@nokia.com 7 References [2719] RFC 2719, "Framework Architecture for Signaling Transport" [RANAP] 3G TS 25.413 V3.0.0 (2000-01) 'Technical Specification 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu Interface RANAP Signalling' [SCTP] Stream Control Transport Protocol , April 19, 2000, Work in Progress. [M3UA] MTP3-User Adaptation Layer , March 2000, Work in Progress. [2401] RFC 2401, "Security Architecture for the Internet Protocol", S. Kent, R. Atkinson, November 1998. [UTRAN IUR] 3G TS 25.420 V3.0.0 (2000-01) "Technical Specification 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iur Interface General Aspects and Principles" [2196] RFC 2196, "Site Security Handbook", B. Fraser Ed., September 1997. [ENUM] "ENUM Requirements" , June 2000, Work in Progress. [E.164-DNS] "E.164 number and DNS" , , April 25, 2000, Work in Progress. Copyright (C) The Internet Society (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. 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 Loughney [Page 7] Internet Draft IP based Signaling Needs in RANs June 16, 2000 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Loughney [Page 8]