IMS protocol study for Video monitoring service & IMS market evolution

Transcription

1 IMS protocol study for Video monitoring service & IMS market evolution Realized by Ahmed GHORBAL

2 Acknowledgments I want to thanks Mr. Insolvibile for all the help, the time and the welcome that he has presented to me during the project, Miss. Landi and Mr. Memeo for her cooperation to realize the project, Mr. Bozzi for his wonderful support, Mr Ciulli and Mr. Martucci for their welcome in Nextworks and all the Nextworks and CPR staff for the friendly atmosphere offered to my person. I want to present a very special thanks to Mr. Manfroni for all the help that he presented to me during all the master duration; and I want to acknowledge him as one of the success key of the IMCNE. A special thanks also to Mr. Castoldi for all his actions and decisions. A special Thanks to the University of Tunis and to Mr. Frikha for all the support for the IMCNE group. Finally I want to thank all teachers of the IMCNE. Ahmed GHORBAL Page 2 IMCNE internship

3 Index Introduction Nextworks PA-IMS Project technologies SIP SIP functionality SIP Architecture SIP addressing SIP methods SIP communication example SDP Overview SDP Format SDP exemple Diameter protocol Introduction Diameter Protocol TYPES OF DIAMETER NODES Diameter Message Format Diameter AVP Format The Diameter Identity Diameter Message Content and Routing Diameter protocol Diameter vs RADIUS NSIS Overview NSIS fundamentals Design choices PA-IMS architucture IMS elements Call Session Control Function (CSCF) P-CSCF I-CSCF S-CSCF Non IMS elements Breakout Gateway Control Function (BGCF) Interconnection Border Control Function (IBCF) Media Gateway Control Function (MGCF) IMS-Media Gateway Function (IMS-MGW) Application Server (AS) Signaling Gateway Function (SGF) Networking With PSTN: Ahmed GHORBAL Page 3 IMCNE internship

4 4.3.2 With IP-Based service subsystem References points HSS CSCF (Cx Reference Point) CSCF UE (Gm Reference Point) MGCF CSCF (Mg Reference Point) CSCF - MRFC (Mr Reference Point) CSCF CSCF (Mw Reference Point) CSCF BGCF (Mi reference point) BGCF MGCF (Mj reference point) BGCF/IBCF BGCF (Mk reference point) CSCF- SLF (Dx Reference Point) MGCF - T-MGF/ IM-MGW (Mn Reference Point) UE AS (Ut Reference Point) HSS OSA SCS (Sh Reference Point) S-CSCF AS (ISC Reference Point) I-CSCF AS (Ma Reference Point) Procedure UE IMS network UE- CSCF procedure Application level registration procedures RACS functions and QoS relation: Market evolution IMS position IMS sales estimations Providors solutions: Ericsson solution: Alcatel-Lucent solution Italtel solution Conclusion Reference Ahmed GHORBAL Page 4 IMCNE internship

5 Introduction The Internet Protocol (IP) is ubiquitous: according to the Internet Society it is used to interconnect more than 1 billion people all over the world. More than 15% of the world population now has access to the Internet and this penetration rate has doubled between 2000 and The Internet provides interoperability at a very large scale, enabling people using different terminals to communicate. While the first generation of the Internet was mostly dedicated to the transport of non real time data, services with stringent Quality of Service (QoS) requirements are now largely adopted (e.g. Telephony over IP (ToIP), Video-conferencing). Moreover the share of the multimedia services in operator s revenue is expected to grow in the next few years. The move toward all IP architecture for service delivery appears to be a strong trend. In this context, customers seem to desire an access to personalized interactive, multimedia services, on any device, and anywhere. This trend introduces new requirements for network infrastructures. The IP Multimedia Subsystem (IMS) is seen as a promising solution for fulfilling these expectations. IMS refers to a functional architecture for multimedia service delivery, based upon Internet protocols. Its aim is to merge Internet and cellular worlds, in order to enable rich multimedia communications [2, 3]. It is specified in the 3rd Generation Partnership Project (3GPP). IMS was introduced in UMTS release 5 (March 2003) and 6 [4]. In its first version, it focused on facilitating the development and deployment of new services in mobile networks [4]. It was later extended by the European Telecommunication Standards Institute (ETSI), in the scope of its work on Next Generation Networks (NGNs) 2. A standardization body of ETSI, called Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) standardizes IMS as a subsystem of NGNs. TISPAN has published a first release of ETSI IMS standards and is currently working on a second release. Most of the IMS protocols are standardized by the Internet Engineering Task Force (IETF) (e.g. the Session Initiation Protocol (SIP)). Other standardization bodies are involved in the development of IMS. For example, the Open Mobile Alliance publishes additional service related requirements (e.g. Push to talk over Cellular (PoC) [6]) and leads interoperability related operations. 1 Nextworks NeXtworks is an advanced telecommunications technologies service provider, and in particular, of wireless access networks, Carrier Grade architectures, telephony on IP and digital video coding.. Its mission is to anticipate the innovation of the infrastructures of telecommunications with projects R&D advanced and united with the requests of the market. Taking advantage of the immense experience and collaboration matured with important providers and operators of the European panorama, nextworks is in a position to supply innovative solutions with competitive costs in the areas of the fixed telephony and mobile, Ahmed GHORBAL Page 5 IMCNE internship

6 of networking and the multimedia, offering the own competences to various customers of wrap and typology.. 2 PA-IMS Project PA-IMS is a ministerial project with the collaboration of Italtel, a leader in convergence network solutions provider. The target of the project is to implement the video monitoring for IMS users, fixed and mobile customers. 3 technologies 3.1 SIP SIP Session Initiation Protocol, defined in the IETF RFC 3261, is an application layer protocol to initiate sessions used to establish, modify and terminate multimedia sessions. Its basic scope is to exchange IP address and port address to let systems receiving data SIP functionality In order to manage multimedia sessions SIP propose a series of functionalities. So the User location will determine the end system to be used for communication (2G, 3G, PLMN ), the user availability determines the Willingness of the called party to engage in communication, user Capability determines the media and its parameter to be used (codec supported, rate supported..). The Session Setup allows the ringing, session parameters establishment at both called and calling party and the Session Management functionality allows Transfer and termination of sessions, modify session parameters and invoke services SIP Architecture SIP introduces different type of nodes. User agent and Proxy server are the two types of node in SIP architecture. User Agent can be a User Agent Client (UAC) or a User Agent Server (UAS). UAC creates new SIP request instead the UAS generates responses to a SIP request (accept, reject, redirect). UAS can be a Registrar Server witch accepts REGISTER requests and places the information into a database or a Redirect Server witch Redirect Requests based on a location service The Proxy Server routes SIP Requests to UAS and SIP response to UAC. Ahmed GHORBAL Page 6 IMCNE internship

7 3.1.3 SIP addressing SIP uses uniform Resource Locators (URL), the format of the URL is: example: SIP methods SIP presents different methods for the different types of uses. This is the list of all SIP methods with the type of use. REGISTER: Binds a permanent address to a current location Invite: initiates sessions ACK: confirm BYE: terminates sessions CANCEL: cancel pending INVITE; SIP communication example Let s take the example, two SIP users Alice and Bob, Alice belongs to Nextworks home network and Bob belongs to AGcom one. AGcom.com Registrar Nextworks.com proxy AGcom.com proxy Figure 1: SIP communication Ahmed GHORBAL Page 7 IMCNE internship

8 BoB Registration: REGISTER sip:registrar.agcom.com SIP/2.0 Via: SIP/2.0/UDP bobspc.agcom.com:5060 ;branch=z9hg4bknashds7 Max-Forwards: 70 To: Bob From: Bob ;tag= Call-ID: CSeq: 1826 REGISTER Contact: Expires: 7200 Content-Length: 0 The Request-URI names the domain of the location service for which the registration is meant The To header field contains the address of record whose registration is to be created The From header field contains the address-of-record of the person responsible for the registration. The value is the same as the To header field unless the request is a thirdparty registration. All registrations from a UA should use the same Call-ID header field value for registrations sent to a particular registrar. The CSeq value guarantees proper ordering of REGISTER requests. A UA must increment the CSeq value by one for each REGISTER request with the same Call-ID. The Contact header field with zero or more values containing address bindings The Expires header field indicates how long the UA would like the binding to be valid. The value is a number indicating seconds Bob Registration Settlement This message is sent by the AGcom Registra server to confirm the registration of BoB. SIP/ OK Via: SIP/2.0/UDP bobspc.agcom.com:5060;branch=z9hg4bknashds7 ;received= To: Bob <sip:bob@agcom.com> ;tag=2493k59kd From: Bob <sip:bob@agcom.com> ;tag= Call-ID: @998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:bob@ > Expires: 7200 Content-Length: Invite message Alice's user agent (UA) does not know the location of Bob's UA or his server in the AGcom.com domain. Therefore, the INVITE request is sent to the SIP server that serves Alice's domain (nextworks.com). The address of the nextworks.com SIP server could have been configured in Alice's softphone, or it could have been discovered by DHCP, for example. INVITE sip:bob@agcom.com SIP/2.0 Ahmed GHORBAL Page 8 IMCNE internship

9 Via: SIP/2.0/UDP pc33.nextworks.com;branch=z9hg4bknashds8 Max-Forwards: 70 To: Bob From: Alice Call-ID: a84b4c76e66710 CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: The initial Request-URI of the message is set to the value of the URI in the To field. - The Via header field indicates the transport (UDP) used for the transaction and identifies the location -- sent-by (pc33.nextworks.com) -- where the response is to be sent. The "branch" parameter is used to identify the transaction created by that request. It is mandatory and must always begin with the characters "z9hg4bk". - The Max-Forwards header field serves to limit the number of hops a request can transit on the way to its destination. It is decremented by one at each hop. - The To header field specifies the desired "logical" recipient of the request, or the address-of-record (AOR) of the user or resource that is the target of this request. There is no "tag" parameter since the dialog is not established yet. - The From header field indicates the logical identity of the initiator of the request, possibly the user's address-of-record. "Alice" is the (optional) display name. The "tag" parameter identifies this UA as a peer of the dialog. - The Call-ID header field acts as a unique identifier and must be the same for all requests and responses sent by either UA in a dialog. - The CSeq header field serves as a way to identify and order transactions. It consists of a sequence number and a method, matching that of the request. - The Contact header field provides a SIP or SIPS URI that can be used by Bob's UA to contact Alice's UA for subsequent requests. - The Content-Type header field indicates the media type of the message-body sent to the recipient. SDP (session description protocol) is defined in RFC trying response The "nextworks.com" proxy server, first answer Alice by a «Trying» message and finds the SIP proxy server that serves the "AGcom.com" domain by performing a particular type of DNS lookup. This procedure (selecting a transport protocol, determining port and IP address) is described in RFC3263 (SIP: Locating SIP Servers). SIP/ Trying Via: SIP/2.0/UDP pc33.nextworks.com;branch=z9hg4bknashds8 ;received= To: Bob <sip:bob@agcom.com> From: Alice <sip:alice@nextworks.com>;tag= Call-ID: a84b4c76e66710 CSeq: INVITE Content-Length: 0 The 100 (Trying) response contains the same To, From, Call-ID, CSeq header field values as the INVITE request. The "received" parameter is added to the Via header field by the "server transport" of Ahmed GHORBAL Page 9 IMCNE internship

10 nextworks.com proxy, after examining the value of the sent-by parameter (pc33.nextworks.com). This sent-by parameter was inserted by the UA's "client transport" in the Via header field value, just before sending the INVITE request. The sent-by field contained an IP address or host name, and port. The "received" parameter contains the IP source address from which the packet was received Inviting called party home network proxy Before forwarding the INVITE request, the "nextworks.com" server adds an additional Via header field value that contains its own address -- sent-by (bigbox3.site3.nextworks.com) -- and the "branch" transaction value. INVITE SIP/2.0 Via: SIP/2.0/UDP bigbox3.site3.nextworks.com;branch=z9hg4bk77ef4c Via: SIP/2.0/UDP pc33.nextworks.com;branch=z9hg4bknashds8 ;received= Max-Forwards: 69 To: Bob From: Alice Call-ID: a84b4c76e66710 CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 142 The "received" parameter is added to the Via header field built by Alice's UA (as for "100 Trying" message). Max-Forwards is decremented by one The remainder of the INVITE request received from Alice's UA is unchanged. The remainder of the INVITE request received from Alice's UA is unchanged Called party home network answer of the invite SIP/ Trying Via: SIP/2.0/UDP bigbox3.site3.nextworks.com;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33.nextworks.com;branch=z9hg4bknashds8 ;received= To: Bob From: Alice ;tag= Call-ID: a84b4c76e66710 CSeq: INVITE Content-Length: 0 The "received" parameter is added to the Via header field built by "nextworks.com" proxy server Invite the called party Before forwarding the INVITE request, the "AGcom.com" server adds an additional Via header field value that contains its own address Ahmed GHORBAL Page 10 IMCNE internship

11 INVITE SIP/2.0 Via: SIP/2.0/UDP server10.agcom.com;branch=z9hg4bk4b43c2ff8.1 Via: SIP/2.0/UDP bigbox3.site3.nextworks.com;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33.nextworks.com;branch=z9hg4bknashds8 ;received= Max-Forwards: 68 To: Bob From: Alice Call-ID: a84b4c76e66710 CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 142 Max-Forwards is decremented by one The remainder of the INVITE request received from "nextworks.com" proxy server is unchanged Called party answer Bob's SIP phone rings and indicates this in a 180 (Ringing) response, which is routed back in the reverse direction to AGcom.com proxy (IP address and transport found in the top Via header field) SIP/ Ringing Via: SIP/2.0/UDP server10.agcom.com;branch=z9hg4bk4b43c2ff8.1 ;received= Via: SIP/2.0/UDP bigbox3.site3.nextworks.com;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33.nextworks.com;branch=z9hg4bknashds8 ;received= To: Bob <sip:bob@agcom.com>;tag=a6c85cf From: Alice <sip:alice@nextworks.com>;tag= Call-ID: a84b4c76e66710 Contact: <sip:bob@ > CSeq: INVITE Content-Length: 0 The "received" parameter is added to the Via header field built by "AGcom.com" proxy server The Contact header field provides a SIP or SIPS URI that can be used by Alice's UA to contact Bob's UA for subsequent requests. The "tag" parameter, identifying this UA as a peer of the dialog, is added to the To header field. Although the dialog is not established yet, the 3 values that identify a dialog (Call-ID, local Tag, remote Tag) are already defined. The other header field values (From, Call-ID, CSeq, and bottom Via's) are copied from the INVITE request inter proxy Ringing message SIP/ Ringing Via: SIP/2.0/UDP bigbox3.site3.nextworks.com ;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33.nextworks.com Ahmed GHORBAL Page 11 IMCNE internship

12 ;branch=z9hg4bknashds8 ;received= To: Bob ;tag=a6c85cf From: Alice ;tag= Call-ID: a84b4c76e66710 Contact: CSeq: INVITE Content-Length: 0 The top Via header field in the 180 (Ringing) message received from Bob's UA, is used by AGcom.com proxy server for retrieving the relevant transaction, using the "branch" parameter. It is then removed and the information in the new top Via header field is used for forwarding the message towards the next hop in the reverse path: nextworks.com proxy Calling entity Ringing Message SIP/ Ringing Via: SIP/2.0/UDP pc33.nextworks.com ;branch=z9hg4bknashds8 ;received= To: Bob <sip:bob@agcom.com> ;tag=a6c85cf From: Alice <sip:alice@nextworks.com> ;tag= Call-ID: a84b4c76e66710 Contact: <sip:bob@ > CSeq: INVITE Content-Length: 0 The top Via header field in the 180 (Ringing) message received from AGcom.com proxy, is used by nextworks.com proxy server for retrieving the relevant transaction, using the "branch" parameter. It is then removed and the information in the new top Via header field is used for forwarding the message towards the next hop in the reverse path: Alice's UA. Alice's softphone passes the Ringing information to Alice, using an audio ringback tone or by displaying a message on Alice's screen Bob answer message When Bob answers the call, his SIP phone sends a 200 (OK) response to indicate that the call has been answered. The 200 (OK) contains a message body with the SDP media description of the type of session that Bob is willing to establish with Alice. SIP/ OK Via: SIP/2.0/UDP server10.agcom.com ;branch=z9hg4bk4b43c2ff8.1 ;received= Via: SIP/2.0/UDP bigbox3.site3.nextworks.com ;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33.nextworks.com Ahmed GHORBAL Page 12 IMCNE internship

13 ;branch=z9hg4bknashds8 ;received= To: Bob ;tag=a6c85cf From: Alice ;tag= Call-ID: a84b4c76e66710 CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 131 "CSeq: INVITE" / "branch=z9hg4bk4b43c2ff8.1" transaction, between AGcom.com proxy an Answering message between proxies SIP/ OK Via: SIP/2.0/UDP bigbox3.site3.nextworks.com;branch=z9hg4bk77ef4c ;received= Via: SIP/2.0/UDP pc33.nextworks.com;branch=z9hg4bknashds8 ;received= To: Bob <sip:bob@agcom.com> ;tag=a6c85cf From: Alice <sip:alice@nextworks.com> ;tag= Call-ID: a84b4c76e66710 CSeq: INVITE Contact: <sip:bob@ > Content-Type: application/sdp Content-Length: 131 "CSeq: INVITE" / "branch=z9hg4bk77ef4c " Transaction, between AGcom.com proxy and nextworks.com proxy, terminates with this 200 (OK) response calling part informed by the answer SIP/ OK Via: SIP/2.0/UDP pc33.nextworks.com;branch=z9hg4bknashds8 ;received= To: Bob <sip:bob@agcom.com> ;tag=a6c85cf From: Alice <sip:alice@nextworks.com> ;tag= Call-ID: a84b4c76e66710 CSeq: INVITE Contact: <sip:bob@ > Content-Type: application/sdp Content-Length: 131 "CSeq: INVITE" / "branch=z9hg4bknashds8" transaction, between nextworks.com proxy and Alice's UA, terminates with this 200 (OK) response Alice's softphone stops the ringback tone and indicates that the call has been answered. Ahmed GHORBAL Page 13 IMCNE internship

14 Calling part ACK Alice's softphone sends an ACK (message request) to Bob's SIP phone to confirm the reception of the final response (200 (OK)). In this example, the ACK is sent directly from Alice's softphone to Bob's SIP phone, bypassing the two proxies. This occurs because the endpoints have learned each other's address from the Contact header fields through the INVITE/200 (OK) exchange, which was not known when the initial INVITE was sent. ACK SIP/2.0 Via: SIP/2.0/UDP pc33.nextworks.com ;branch=z9hg4bknashds9 Max-Forwards: 70 To: Bob ;tag=a6c85cf From: Alice ;tag= Call-ID: a84b4c76e66710 CSeq: ACK Content-Length: Data transfer Alice and Bob's media session has now begun, and they send media packets using the format to which they agreed in the exchange of SDP. In general, the end-toned media packets take a different path from the SIP signaling messages. One or a combination of the following media types can be used with SDP: "audio", "video", "application", "data", "control" Called part end message At the end of the call, Bob disconnects (hangs up) first and his SIP phone generates a BYE (request) message. This BYE is routed directly to Alice's softphone, again bypassing the proxies. BYE sip:alice@pc33.nextworks.com SIP/2.0 Via: SIP/2.0/UDP ;branch=z9hg4bknashds10 Max-Forwards: 70 From: Bob <sip:bob@agcom.com> ;tag=a6c85cf To: Alice <sip:alice@nextworks.com> ;tag= Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: confirming end Alice confirms receipt of the BYE with a 200 (OK) response, which terminates the Ahmed GHORBAL Page 14 IMCNE internship

15 session and the BYE transaction. SIP/ OK Via: SIP/2.0/UDP ;branch=z9hg4bknashds10 From: Bob ;tag=a6c85cf To: Alice ;tag= Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: SDP Overview SDP is used to describe multimedia sessions in a format understood by the participants over a network. The purpose of SDP is to convey information about media streams in multimedia sessions to help participants join or gather info of a particular session. SDP includes Session name and purpose Time(s) the session is active The media comprising the session Information to receive those media (addresses, ports, formats and so on) SDP Format SDP is a short structured textual description It conveys the name and purpose of the session, the media, protocols, codec formats, timing and transport information The owner of a conference advertises it over the network by sending multicast messages which contain description of the session. Depending on that information, the recipients of the advertisement take a decision about participation in the session. Session description (* denotes optional ) v= (protocol version) o= (owner/creator and session identifier) s= (session name) i=* (session information) u=* (URI of description) e=* ( address) p=* (phone number) c=* (connection information -not required if included in all media) b=* (bandwidth information) z=* (time zone adjustments) Ahmed GHORBAL Page 15 IMCNE internship

16 k=* (encryption key) a=* (zero or more session attribute lines) Time description (* denotes optional ) t= (time the session is active) r=* (zero or more repeat times) Media description (* denotes optional ) m= (media name and transport address) i=* (media title) c=* (connection information -optional if included at session-level) b=* (bandwidth information) k=* (encryption key) a=* (zero or more media attribute lines) SDP exemple An example of a SDP message is v=0 o=mbaye IN IP s=sdp Seminar i=a Seminar on the session description protocol u= e=msf@itn.edu (Manda Baye) c=in IP /127 t= a=recvonly m=audio RTP/AVP 0 m=video RTP/AVP 31 m=application 32416udp wb a=orient:portrait 3.3 Diameter protocol Introduction The RADIUS protocol (Remote Access Dial In User Services) has been widely and successfully deployed to provide authentication, authorization, and accounting (AAA) services for dial-up PPP/IP and Mobile IP access. However, inherent shortcomings of the RADIUS protocol have limited its ability to adapt to the ever-increasing capabilities of routers and network access servers, and the ever-expanding set of desired AAA services. Ahmed GHORBAL Page 16 IMCNE internship

17 The Diameter protocol was designed as an improved version of the RADIUS protocol. A goal was to maximize compatibility and ease migration from RADIUS to Diameter. Diameter is defined in terms of a base protocol and a set of applications. This design allows the protocol to be extended to new access technologies. The base protocol provides basic mechanisms for reliable transport, message delivery, and error handling. The base protocol must be used in conjunction with a Diameter application. Each application relies on the services of the base protocol to support a specific type of network access. The two major applications are Mobile IPv4 and NASREQ (Network Access Server REQuirements). The NASREQ application supports dial-in PPP/IP and is the intended replacement for RADIUS Diameter Protocol The Diameter model is a base protocol and a set of applications. The base protocol provides common functionality to the supported applications. The following figure depicts the Diameter architecture. Figure 2: Diameter protocol The base protocol defines the basic Diameter message format. Data is carried within a Diameter message as a collection of Attribute Value Pairs (AVPs). An AVP consists of multiple fields: an AVP Code, a Length, some Flags, and Data. Some AVPs are used by the Diameter base protocol; other AVPs are intended for the Diameter application (e.g. NASREQ); while yet others may be used by the higher-level end-system application that employs Diameter TYPES OF DIAMETER NODES In addition to clients and servers, the Diameter protocol defines relay, proxy, redirect, and Ahmed GHORBAL Page 17 IMCNE internship

18 translation agents. Client A Diameter Client is a device at the edge of the network that performs access control. Examples of Diameter clients are Network Access Servers (NAS) and mobility agents (Foreign Agent). Server A Diameter Server is one that handles authentication, authorization, and accounting requests for a particular realm. Relay Agent A Relay Agent routes Diameter messages based on information found in the messages. This routing decision is performed using a list of supported realms and known peers. Relay agents are largely transparent. A Relay Agent may modify Diameter messages only by inserting and/or removing routing information but may not modify any other portion of a message. Proxy Agent A Proxy agent also routes Diameter messages. However, a proxy agent may modify messages to implement policy decisions, such as controlling resource usage, providing admission control, and provisioning. Redirect Agent A redirect agent also provides a routing function, generally acting as a centralized source of RealmServer address mappings for members of a roaming consortium. Unlike the other agents that relay requests, a redirect agent returns a special type of answer message to the peer that sent the request. This answer message contains routing information that allows the peer to resend the request directly to the correct destination server. The redirect agent is then out of the routing path; a redirect agent does not relay requests. Translation Agent A Translation Agent translates between two protocols, such as RADIUS and Diameter. In this case, the translation agent supports a RADIUS to Diameter migration, allowing server conversions to Diameter, for example, while permitting the NASes to be converted at a slower pace Diameter Message Format A Diameter message consists of a fixed-length 20-octet header followed by a variable number of AVPs. The format of a Diameter message is: Version Message Length Flags R P E x x x x x Command-Code Ahmed GHORBAL Page 18 IMCNE internship

19 Vendor-ID Hop-by-Hop Identifier End-to-End Identifier AVPs... The Diameter message header contains two 32-bit message identifiers, a Hop-by-Hop Identifier and an End-to-End Identifier. The Hop-by-Hop Identifier aids in matching requests and replies. In requests, the Hop-by- Hop Identifier is replaced at each hop as the Diameter message is relayed to its final destination. The sender of an Answer message returns the same value that was found in the corresponding request. The End-to-End Identifier, in conjunction with the origin host's identity, is used to detect duplicate request messages. The End-to-End Identifier is unmodified as a request is forwarded to its final destination. The originator of an Answer message returns the same value that was found in the corresponding request Diameter AVP Format The format of a Diameter AVP is: AVP code Flags : V M P x x x x x AVP Length Vendor-ID (if vendor-specific AVP) AVP Data... (variable length) Figure 3: Diameter AVP Format The AVP Code plus the Vendor-Id field uniquely identify the attribute. The first 256 AVP numbers, with the Vendor-Id set to zero, are reserved for backward compatibility with RADIUS. The AVP Data field is zero or more octets and contains information specific to the Attribute. The AVP Code and AVP Length fields determine the format and length of the Data field. Diameter defines data types of Integer32, Unsigned32, Integer64, Unsigned64, Float32, Float64, Float128, OctetString, and Grouped. A Grouped AVP is an AVP whose data is a sequence of AVPs. The other types are selfexplanatory. Derived data formats are also defined, including enumerated (derived from integer32), DiameterIdentity (derived from octetstring), and time (derived from unsigned32), and UTF8String (derived from octetstring), IPFilterRule (derived from octetstring), and QosFilterRule (derived from octetstring). Ahmed GHORBAL Page 19 IMCNE internship

20 3.3.6 The Diameter Identity Each Diameter process running on a host generates, or is configured with, a Diameter Identity. The Diameter Identity is a URI-syntax string with substrings representing the host's fully qualified domain name (FQDN), one of the ports used to listen for incoming connections, the transport used to listen for incoming connections (i.e. TCP or SCTP), the AAA protocol (i.e. Diameter), and the transport security (i.e. none or TLS). The following is an example of a valid Diameter host identity: aaa://host.abc.com:1812;transport=tcp;protocol=diameter Since the identity carries the host's FQDN, and since multiple Diameter processes on a single host cannot listen for incoming connections on the same port on a given protocol, the Diameter Identity of any process is guaranteed to be unique Diameter Message Content and Routing A Diameter message consists of a fixed-length header followed by a variable number of AVPs. There are two types of messages, Requests and Answers. There are few circumstances where a request is silently discarded, so in general the originator of a request will receive an answer. Every answer message carries a Result-Code AVP. The data value of the Result-Code AVP is an integer code indicating whether a particular request was completed successfully or whether an error occurred. Every Diameter message carries the Diameter Identity of the originating Diameter process in the Origin-Host AVP. Every Diameter message carries the realm of the originating Diameter process in the Origin-Realm AVP. Request messages may be proxiable or non-proxiable, indicated by a flag in the message header. Non-proxiable requests are intended strictly for the next-hop peer, and are never forwarded. Proxiable requests are routable and are routed by realm. Every proxiable request carries the target realm in the Destination-Realm AVP. A Diameter message pertaining to a specific user session includes a Session-Id AVP, the value of which is constant throughout the life of a session. The value of the Session-Id AVP is a globally and eternally unique text string, intended to uniquely identify a user session without reference to any other information. The Diameter client initiating the session creates the Session-Id. The Session-Id begins with the originator's Diameter Identity string and is followed by any sequence guaranteeing both topological and temporal uniqueness. Ahmed GHORBAL Page 20 IMCNE internship

21 3.3.8 Diameter protocol Diameter vs RADIUS THE CASE FOR DIAMETER RADIUS Size of attribute data Number of concurrent pending messages servers control flow server failure detection packets discarding Server Fail- Over A RADIUS attribute is carried in a RADIUS message as a variable-length {Attribute Type, Attribute Length, Attribute Value} 3-tuple. The Attribute Length field is one octet; hence its maximum value of 255 puts a ceiling on the number of octets of a given attribute's data. An Identifier field in the header of the RADIUS packet is used to recognize retransmissions. It is one octet, imposing a maximum of 255 outstanding messages between a client and a server. RADIUS operates over UDP, a simple connectionless datagram delivery transport protocol that lacks any mechanism for the receiving node to regulate the data flow from the sending node With RADIUS/UDP, the NAS cannot distinguish the cause of the failure, assumes failure of the next-hop server and retransmits to an alternate next hop server. This may be an inappropriate failover The RADIUS protocol specifies that messages are silently discarded for a variety of error conditions. In such cases, the NAS will assume the home server did not receive the message, and will engage in futile retransmissions before finally abandoning the request. Most NAS implementations configure multiple RADIUS servers, a primary server and a set of alternate servers. When failing over to an alternate, the NAS doesn't know if the alternate server is even reachable. This can result in a lengthy delay of service to users until a suitable alternate is found Diameter A Diameter attribute is carried in a Diameter message as a variablelength {Attribute Type, Flags, Attribute Length, Vendor-ID, Attribute Value} 5-tuple. The Attribute Length field is three octets, hence its maximum value allows for over 16,000,000 octets of data for a given attribute. An End-to-End Identifier field in the header of a Diameter message is used to recognize retransmissions. This field is four octets, allowing over 4 billion outstanding messages from a Diameter client. Diameter operates over TCP or SCTP. TCP and SCTP are connection-oriented transport protocols with flow control and congestion avoidance mechanisms. With a connection-oriented transport layer and Diameter keepalive messages, a Diameter node can detect the local failure of a peer. The Diameter protocol returns a response for all but a few error conditions. With a connection-oriented transport layer and Diameter keepalive messages, a Diameter nodes can effectively failover. It can also fail back to the primary server when it becomes available without having to time out real requests Ahmed GHORBAL Page 21 IMCNE internship

22 proxy Unsolicited server messages End-to-End security support for vendorspecific commands Alignment requirements Shared Secret Under RADIUS, all retransmissions are done by the NAS. Proxy servers do not retransmit RADIUS requests. The NAS, not knowing whether the failure is local or remote, may inappropriately retransmit to an alternate next-hop peer The RADIUS protocol does not allow a server to send unsolicited messages to the NAS. Where server initiated actions are needed, vendors are forced into solutions outside of the RADIUS protocol (e.g. SNMP) or solutions involving proprietary extensions to the RADIUS protocol in ways that often compromise interoperability. The RADIUS protocol offers only hopby-hop security and has no facility for securing AVPs between the NAS and the home server. This offers proxy servers the opportunity to collect confidential information or modify messages without detection by the endpoints. The RADIUS protocol supports vendorspecific attributes but not vendorspecific commands. This has enticed vendors to create private command codes with resulting interoperability problems. The RADIUS protocol imposes no alignment requirements, which can add an unnecessary burden on many processors. All fields within the header and attributes must be treated as byte aligned characters. The RADIUS protocol requires that a shared secret exist between two peers, even if IP Security is employed over a local communication Table 1: Radius vs Diameter Under the Diameter protocol, each Diameter node that a message traverses on the path from the origin node to the home server will detect a failure of his next-hop peer and do failover and retransmission. Thus, failovers are locally performed at the place where the failures occur. Diameter, a peer-to-peer rather than a client/server protocol, allows serverinitiated messages. The base protocol defines two server-initiated messages, one requesting that the Diameter client terminate a specific user session, another requesting that the Diameter client re-authenticate and/or reauthorize a specific user. The Diameter protocol offers end-toend security in addition to hop-by-hop security. Digital signatures can ensure the integrity of selected AVPs, and the confidentiality of selected AVPs can be ensured by encryption. The Diameter protocol supports both vendor-specific attributes and vendorspecific commands. The Diameter protocol requires all attributes to align on 32-bit boundaries. Individual 32-bit fields in the Diameter message header and AVP header also align on 32-bit boundaries. The Diameter protocol can secure communications between peers with either IP Security or Transport Layer Security (TLS). Here are the Benefits of Diameter comparing to RADIUS. Better Transport Diameter runs over a reliable transport, TCP or SCTP. Ahmed GHORBAL Page 22 IMCNE internship

23 Lost packets are retransmitted at each hop. A persistent connection with an application-level heartbeat message (called a Watchdog message) supports timely failover. TCP and SCTP adapt to network congestion. Better Proxying Hop-by-hop transport failure detection allows failover to occur at the appropriate place Proxies can locally failover to an alternate next-hop peer. The proxy automatically does retransmission of pending request messages following a failover. An AVP that identifies the ultimate destination allows multiple transactions for a given session to be routed to the same home server. Better Session Control Session management is independent of accounting. Accounting information can be routed to a different server than authentication/authorization messages. Session termination is conveyed by a specific Session-Termination message rather than an Accounting Stop message. The server may initiate a message to request session termination. The server may initiate a message to request re-authentication and/or reauthorization of a user. Better Security Hop-by-hop security is provided using IPsec or TLS. End-to-end security protects the integrity and/or confidentiality of sensitive AVPs through 3.4 NSIS Overview Both the explosive growth of the Internet and the increase in real time multimedia services involved the necessity of adding those QoS features to the existing Internet infrastructure, in addition to the mobility application need. The Internet Engineering Task Force (IETF) designed the Protocol RSVP to fit these needs, but this protocol turned out to suffer from a lack of flexibility to meet today s requirements. RSVP: Can only supports receiver-initiated signaling Can only supports unidirectional path reservation is transport protocol dependent (UDP if transport protocol is to be used) lacks separation between member discovery and actual signaling has limited signaling scope variation (RSVP is mainly for end-to-end signaling) Ahmed GHORBAL Page 23 IMCNE internship

24 has limited multicast support has limited mobility support Due to these shortcomings, the NSIS working group began to work on a new protocol suite in order to accommodate new signaling needs NSIS fundamentals NSIS entities (NEs) communicating with each others are referred to as peers. The initiator of the signaling is called NSIS initiator (NI) and nodes along the signaling path intercepting and forwarding messages are called NSIS forwarders (NFs). Finally, the entity terminating the NSIS signaling is called the NSIS responder (NR). There is no requirement for all the routers along the data path between the NI and NR being NSIS aware nor do all NSIS nodes necessarily support all signaling applications. Figure 1 shows a diagram of nearly the simplest possible signaling configuration. A single data flow is running from an application in the sender to the receiver via routers R 1, R 2, and R 3. Each host and two of the routers contain NEs that exchange signaling messages about the flow. Sender NI R 1 R 3 NE R 2 NE Receiver NR Signaling Messages Data Flow Messages Figure 1: Simple Signaling and Data Flows Design choices The fundamental design choices for the NSIS protocol suite are summarized below Separating Signaling Message Transport from Signaling Application In order to meet the requirements for extensible, generic signaling, the design of the NSIS protocol suite separates the functionalities such as reliability, fragmentation, congestion control and integrity for signaling message transport from signaling applications. Thus, architecturally, NSIS consists of two protocol layers: An NSIS Transport Layer Protocol or NTLP, primarily composed of a specialized messaging layer, denoted as GIST (General Internet Signaling Transport protocol), Ahmed GHORBAL Page 24 IMCNE internship

25 which is used to transport the signaling application layer messages. The GIST layer is running over standard transport and security protocols. Examples of such transport protocols are UDP, TCP, SCTP, and DCCP. It has two modes of operation: datagram mode, which uses UDP as a default choice, and connection mode, which uses TCP as the initial choice. It maintains two types of states: a per-flow message routing state and a message associated state. GIST can detect route change, update its local routing state consistently, and inform applications at affected nodes. GIST is IP version neutral, but in mixed IPv6 and IPv4 environments, GIST operation is influenced by the IP transition mechanisms in use. NSIS Signaling Layer Protocols or NSLPs, each, running signaling application specific functionality, including formats and processing rules of messages to be exchanged between NSLP peers. Examples of NSLPs include the QoS NSLP for resource reservation signaling and the NAT/firewall NSLP for middle box configuration. NSLPs can support both sender and receiver initiated operation as well as both bidirectional and unidirectional operation. NSLPs also support heterogeneous operation, flow aggregation, acknowledgements and notifications. The NTLP operates at the lower layer, while NSLPs run on the upper layers. The different layers are depicted in the Figure 2. Ahmed GHORBAL Page 25 IMCNE internship

26 NSLP QoS NSLP NAT/Firewall NSLP NSIS GIST (General Internet Signaling Transport Protocol) NTLP Transport Layer Security SCTP TCP DCCP UDP IP Layer Security IP Figure 2: Logical Components in an NSIS-aware Node Decoupling Discovery and Transport of Signaling Messages A design choice that has been made during the NSIS work is to decouple NSIS peer discovery from the signaling message transport mechanism. As known, RSVP combines discovery and signaling message delivery into a single protocol step, thereby preventing standard security protocols or transport layer protocols from being used. NSIS resolves this dilemma by introducing a discovery component in GIST which can rely on IP router alert options or on other approaches, such as routing tables Session Identifier In NSIS, a data flow is defined as a unidirectional sequence of packets between the same end points which all follow a unique path through the network. They are identified by a flow identifier, e.g. a 5-tuple or a DSCP field. NSIS offers a session identifier. A session identifier is a cryptographically random number which is used to probabilistically uniquely Ahmed GHORBAL Page 26 IMCNE internship

27 identify a signaling session and a signaling state, independent of the flow identifier. A session may map to a specific flow, but for some scenarios, signaling applications may create more flexible flow-session relationships: Mobility: during handover, the source or destination IP address of an end host, and hence the flow identifier, may change. This does not affect its installed reservation if the associated session can be remapped to the updated flow identifier. Multi-homing: in this case, multiple flow identifiers can be mapped to the same session. Tunneling and IPv4/v6 traversal: when NSIS signaling messages traverse NSISaware IPv4/v6 borders or other tunneling devices, while the session identifier will remain the same, the flow identifier may be remapped into a different one depending on the signaling application when entering the region. Typically, a session carries opaque per-flow information specific to its NSLP. This information might be related to resource reservation, or some other control function in routers and middle boxes along the path. Support for Signaling to Hosts, Networks and Proxies NSIS signaling is applicable in different parts of the Internet and may be triggered in different ways. This is required to allow the signaling to be initiated and terminated in different parts of the network, namely at end hosts, at domain boundaries (edge nodes) and at interior routers. The NSIS protocol suite thus supports many different signaling exchanges, including end-to-end signaling where the exchange is performed between end hosts, edge-to-edge signaling, where the boundary nodes of a domain might communicate directly and end-to-edge signaling, such as in host-to-network scenarios NSIS Vs RSVP Difference between RSVP and NSIS are summarized in the next table. RSVP NSIS Protocol Structure Single layer Two layers Transport IP or UDP TCP, SCTP, UDP or DCCP Reservation Initiator Receiver Sender or Receiver States Soft+Explicit release Soft+Explicit release QoS Models IntServ/DiffServ IntServ/DiffServ/Y.1541/3gpp Scope of Signaling End-to-End End-to-End/Edge-to- Edge/etc. Multicast Yes No Mobility No Yes Bi-directional No Yes Aggregation Yes Yes Summary refresh Yes Yes Ahmed GHORBAL Page 27 IMCNE internship

28 Priority/Preemption Yes Yes Transport of signaling messages: RSVP messages are transported unreliably by UDP or directly over IP. In NSIS, the message transport mechanism (NTLP) is separated from the signaling application layer (NSLP), thus allowing for different signaling applications. Different applications and sessions can share the same message associations so that it is not necessary to create message associations for each session. NTLP uses existing transport protocols, including UDP and TCP. Reservation model: The RSVP reservation model is receiver-initiated, and its signaling extends from flow sender to flow receiver. NSIS QoS NSLP supports both sender- and receiver-initiated reservations. Proxy operation is supported, i.e., NSIS messages can be initiated and terminated in nodes other than the source or end of the data flow, thus, the scope of NSIS signaling can be end-to-end, edge-to-edge, host-to-edge or edge-to-host. Multicast: Unlike RSVP, NSIS does not support multicast, reducing complexity for the majority of user applications which are unicast. However, the basic NSIS protocol model is likely extensible to IP multicast. Bidirectional reservation: The QoS NSLP supports bidirectional reservations by binding the sessions in both directions. There is no such a support in RSVP. QoS models: NSIS QoS NSLP allows signaling any QoS model. Mobility support: By identifying signaling sessions by a random session identifier, rather than by a flow identifier including the IP address, NSIS can support mobility more easily. Security: Whereas security was added to RSVP after its basic design, NSIS has been designed with security in mind from the beginning, integrating standard security protocols, such as TLS or IPsec/IKEv2. These protocols offer features such as flexible authentication methods, negotiation of crypto algorithms, and extensively verified protocols, and denial of service protection. Similar to RSVP, NSIS can also bypass non-nsis nodes. Furthermore, as NSIS discovery is based on the NSLP type, an NSLP protocol message of type X skips those NSIS nodes not supporting X as non-nslpx clouds, eliminating the need to maintain state in those nodes and reducing signaling latency. Ahmed GHORBAL Page 28 IMCNE internship