IPv4IPv6Inter-workinginIMSbyusingSessionBorder.doc

/kmust1ipv4/ipv6 inter-working in ims by using session bordercontrollercao xinzhounational key laboratory of switching and networking，beijing university of posts andtelecommunications， beijing，prc （100876）e-mail：abstractip multimedia subsystem （ims） is a new network architecture for providing multimedia service inthe next generation networks. the 3rd generation partnership project (3gpp) r5 standards specified the use of internet protocol version 6 (ipv6) for the ims. however, early implementations of ims core and ims clients support internet protocol version 4 (ipv4)-only. as the transition and migration to ipv6 of both the ims core and ims clients, the interoperability between ipv4 and ipv6 in the core region and clients region must be addressed. these issues have the potential to impact the access-independent nature of ims specified by 3gpp. in this paper, we introduce a middleware which is similar to traditional session border controller(sbc) between core and clients, which can handle the inter-working well. and we introduce an interconnect-sbc (i-sbc)-like middleware which can deal with the cross-ims cores communications. in addition, it also can provide other novel features such as anat, ipv6 promotion and make the implementation of user equipment mobility relatively easy.keywords：ims，sbc，ipv6，sip1 introductionthe evolutionary trend of the next generation mobile communication system is obviously towards ip-based networks.3gpp has defined and standardized a network infrastructure called the ip multimedia subsystem (ims) 1 for supporting a multitude of ip multimedia services. ims adopts session initiated protocol (sip) 2 as its signaling protocol and uses session description protocol(sdp) 34 to negotiate the multimedia data transfer. sip is defined by ietf to provide signaling control for multimedia session such as internet telephone calls. it is designed for multimedia session control.ipv6 has been specified by 3gpp r5 to be used in ims. however, because ipv4 is used in the large scale of the existing internets, the early implemented ims core and ims clients support ipv4-only. as both the clients and cores transiting to ipv6, there will be a long period of the co-existence of ipv4 and ipv6, and this will lead to problem for introducing ipv6 clients into the existing ipv4 ims cores, and it is impossible for an ipv6 core to communicate with the ipv4 cores. as ims-based network architectures evolve and become widely accepted as a standards based service creation and delivery framework, theseinter-working problems are urged to be solved. figure 1 shows the challenge of the ipv6 transition in ims:figure 1: the issues related to the inter-working/kmust1an candidate solution is to introduce an element typically referred to as “session border controller” (sbc) 5 between ims cores and clients. this element is now an important component of several voip solutions in real world. the sbc acts as intermediate node in all signaling and media sessions of a user that wants to access the public network through a private access network. from the media point of view the sbc acts as “b2bua” (back to back user agent) while from the signaling point of view it can also act as a sip proxy. in practice the sbc “represents” the user in the public network by providing him/her with a public routable ip address (ipv4 or ipv6) through which the user can be reached even behind a nat.ims is naturally access independent, so we also propose a solution to handle the wireless clients mobility89 for a smooth media handover.the rest of this paper is organized as follows. in section ii we discuss the related background acknowledge. in section iii the sbc-like middleware is described in detail. finally, we conclude this paper in section iv.2 background2.1 imsims is specified in the 3rd generation partnership project/3rd generation partnership project2(3gpp/3gpp2) standards. ims is based upon internet protocols to provide access to multimedia services, converging delivery of voice and data. the ims core network provides the functions at the session management layer of the three-tiered ims structure (i.e., access network, session management, and application services). in this paper, we just simply introduce the session management tier and the related functionality.proxy cscf (p-cscf) - p-cscf is the first point of contact for users with the ims. the p-cscf is responsible for security of the messages between the network and the user and allocating resources for the media flows.interrogating cscf (i-cscf) - i-cscf is the first point of contact from peered networks. the i-cscf is responsible for querying the hss to determine the s-cscf for a user and may also hide the operators topology from peer networks (topology hiding inter-network gateway, or thig).serving cscf (s-cscf) - s-cscf is the central brain. the s-cscf is responsible for processing registrations to record the location of each user, user authentication, and call processing (including routing of calls to applications). the operation of the s-cscf is controlled by policy stored in the hss.dns - the dns server should support ipv6 features such as aaaa type records. the ability of receiving/responding queries through ipv6 is preferred, but not mandatory required.hss - hss should has the ability to store and return fqdns, ipv4 addresses and ipv6 addresses according to specific configurations. the actual implementation and interfaces with other entities do not have influence to the solutions, hence are not necessary to conform to standards (diameter, for example).2.2 ipv6adoption of ipv6 is viewed as the key to deploying next-generation fixed and mobile services. ipv6 is the next-generation internet protocol that succeeds ipv4. the evolution from ipv4 to ipv6 is primarily intended to support the peer-to-peer model of internet connectivity and network efficiency and to encourage innovation. ipv6 supports these by incorporating the following enhancements to ipv4:z expanded ip addressing capabilities,z header format simplification,z stateless address auto-configuration,z improved support for extension headers,z flow labeling capability,z any-cast capability, and inherent support for ipsec and mobile ip (mobip).the greatly increased number of ipv6 globally routable addresses eliminates the need for private addresses and middleboxes such as nats and application-level gateways (algs).2.3 sbcthe term sbc is relatively non-specific, since it is not standardized or defined anywhere. it usually sits between two service provider networks in a peering environment, or between an access network and a backbone network to provide service to residential and/or enterprise customers. they provide a variety of functions to enable or enhance session-based multi-media services (e.g., voice over ip).these functions include: a) perimeter defense (access control, topology hiding, dos prevention, and detection); b) functionality not available in the endpoints (nat traversal, protocol inter-working or repair); and c) network management (traffic monitoring, shaping, and qos). some of these functions may also get integrated into other sip elements (like pre-paid platforms, 3gpp p-cscf,3gpp i-cscf etc).13. implementation of sbcin our implementation of sbc, it is the interface between ues and ims core. it forwards sip signals between access segment and core segment, and forwards media traffic between ues. both the ims core and the ues may have different ip capabilities and running different ip versions.i-sbc is very similar with sbc in functions, and is the interface between different ims domains, these domains may also be different ip realms and running different ip versions. it is commonly used to interconnect different ims operators.sbc run as a as a back-to-back user agents(b2bua) . it typically handle both signaling and media and can implement behavior which is equivalent to a privacy service (as described in2) performing both header privacy and session privacy. sbcs often modify certain sip headers and message bodies that proxies are not allowed to modify. for example, our sbcs modify the session description carried in the message to control the media traffic, replace the value of the contact header field with the sbcs address to do registration for clients and make them routable, generate new to and from tags, and remove via header fields and record route header fields for acheve thig (topology hiding).as a b2bua, sbc receives request from clients uac, at this time, sbc make the role of uasand may send a response back, then it may forward the modified request using its uac. in reverse,sbc will play the role of uac when receiving response, and it may using its uas to forward the response after modification. our sbc starts to handle media stream after the session is established, when it receiving media packet(eg, rtp stream), it will get to know where the packet comes from, and check the “media address mapping” table, then it is aware of where should to forward this packet.figure2 shows our sbc works as b2bua.figure 2: the b2bua model of sbcsince our sbc can modify the header fields of sip request and response, it also can perform the following functions:z nat traversalz access scenarioz ipv4 and ipv6 inter-workingz topology hidingz anat & ipv6 promotionz traffic handover3.1 nat traversalclients are usually located in the private networks, so they are not routable in the public networks. after the introduction of sbc, the clients can be represented by it and the signals and media can be routed to them through sbc. in this case, sbc has two interfaces, one connects to the private networks, and the other connects the public networks.clients that set sbc as their outbound proxy will send register to sbcs private interface, sbc replaces the value of the contact header field with the sbcs address and uses its public interface to forward the register to ims core. at the mean same, sbc will forward the consequent 200 ok response to clients to finish the registration.after the registration, ims core will map the clients address-of-record to the sbcs address, thus, the subsequent requests to the registered clients are routed to the sbc. from the aspect of ims core, sbcs public interface represents all the clients of the private networks.our sbc maintains a registration table, every registration will update this table. it can help to route the incoming sip message to the right client. in addition, sbc make clients to register with itself at a smaller interval by decreasing the value the expire header field of the 200 ok. for example, sbc will make clients register every minute, but it only forwards the register request to ims core every 10 minutes. this can help to enhance the performance of handling clients mobility and improve the user access control and authentication/or authorization.3.2 ipv4 and ipv6 interworkingas the deployment rapid of ipv6 is not as our expectation, most of the existing access networks are supporting ipv4 only. thus, many early implementations of ims core are also supporting ipv4 only, which makes ipv6 clients cant access to these ims core directly. and after the some ims cores upgrade, there will be ipv4 ims core co-exists with ipv6/dualstack ims core. these different cores also cant communicate with each other directly.since our sbc listens on both ipv4 and ipv6 interfaces, hence able to exchange signals and media traffic data with ipv4 clients, ipv6 clients and dual stack ones, and able to interface with ims core using either ipv4 or ipv6, depends on ims cores ip capabilities. so, we can easily solve these two problem by just modify the sip signals. figure 3 shows how an ipv4 client communicates with an ipv6 client with the help of sbc, and figure 4 shows how an ipv4 core communicates with an ipv6core with the help of i-sbc:figure 3 inter-working between ipv4 and ipv6 clientsin figure 3, there are two users, (joey) and (chandler), which have registered with core using ipv4 and ipv6 address, respectively. when joey wants to chat with chandler, it will send an invite request to sbc1s private interface, 7, then sbc1 will forward this invite to core using ipv4 after inserting its public ipv4 address to the sdp. on receiving invite from core side, sbc2 will query its registration table and get chandlers registered address, 2016:90, then it replaces the media address of the session description in the invite with its ipv6 address, 2016:68 and forwards to chandler using its private ipv6 address. the 183 response will go back to joey according to via header fields. during these two steps, sbc1 and sbc2 will update their “media address mapping” table for forwarding media packets.in figure 4, there are two domains, one is , which represents the early implemented ims core, the other is , which can support ipv6. if a cross domain call session is wanted to established, the i-sbc is involved. when it receives invite from the s-cscf of , it will lookup e-dns to get the ipv6 address of the i-cscf of , then it inserts its public ipv6 address into the sdp and forwards the invite to the i-cscf using its publicipv6 interface. in reverse, it will forwards 183 response back to the s-cscf of . this can make the two tie operators to inter-work will each other.3.3 topology hidingtopology hiding consists of limiting the amount of topology information given to external parties. operators have a requirement for this functionality because they do not want the ip addresses of their equipment (proxies, gateways, application servers, etc) to be exposed to outside parties. this may be because they do not want to expose their equipment to dos (denial of service) attacks, they may use other carriers for certain traffic and do not want their customers to be aware of it or they may want to hide their internal network architecture from competitors or partners. the most common form of topology hiding is the application of header privacy (see section 5.1 of 2), which involves stripping via and record-route headers and replacing the contact header.in figure 4, when i-sbc receives sip request from s-cscf of , it will remove the contact header field and all the via header fields and record-route header fields, and before sends out the request to i-cscf of example_, it will insert itself into these three headers fields for called party to generate the back routes of the response. thus, from the point of view, the architecture of is totally transparent.in some deployments which use ip addresses instead of domain names in from and to headers,i-sbc will also replace these ip addresses with its own ip address or domain name.figure 4 inter-working between ipv4 and ipv6 domains3.4 media traffic shaping + ipv6 promotionsince the media path is independent of the signaling path, the media may not traverse through the operators network unless the sbc modifies the session description. by modifying the session description the sbc can force the media to be sent through a media relay which may be co-located with the sbc. or just only to monitor it for collecting statistics and making sure that they are able to meet any business service level agreements with their subscribers and/or partners.so as to accelerate the deployment of ipv6, our sbc should provide mechanism to promote the usage of ipv6 whenever possible, especially in the media plane. we can achieve this ipv6 promotion just by replace the media address in the session description with ipv6 address.however, in the situation of the co-existence of ipv4 clients and cores, ipv6 clients and cores anddual-stack ones, sbc has no idea of the ip capability of next-hop, so as to guarantee the success ofthe session establishment, the sbc will use anat(alternative network address types67) mechanism to discover the ip capability of each call leg and show all its ip capability in the session description offer. the processing procedures relevant to anat are described as follows: when a client receiving invite with the “require= sdp-anat”, it will send 420 response if itdoesnt support anat. when a client receiving invite without the “require= sdp-anat”, it will check the session description, if it doesnt support the media address type, it will send back 606 response when sbc/i-sbc rec