At the SIPit earlier this month, the multiparty testing uncovered a few implementations that assumed that since they only used SIP over IPv4 with protocols like TCP and UDP, they would never encounter an IPv6 addresses or tokens related to other transports like SCTP or DTLS in the SIP messages they receive. This is becoming more unlikely as more advanced transports are being deployed and as we go further into the IPv4 to IPv6
transition.

During rendezvous, a SIP request may traverse several SIP proxies. The RFC 3263 rules for locating the server at each hop can result in different transport protocols.

For example:

The Via stack and the Record-Route stack that are created as the message is forwarded will contain tokens and addresses from each of the traversed networks. Here’s what the Via and Record-Route header fields from the last message in the diagram might look like:

Via: SIP/2.0/UDP 192.0.2.1;received=198.51.100.15;rport=55021;branch=z9hG4bK8h23i5
Via: SIP/2.0/TLS proxy1.example.net;received=[2001:db8::2:1];branch=z9hG4bK3udn3z13
Via: SIP/2.0/SCTP proxy2.example.net;received=198.51.100.18;branch=z9hG4bK23sd093n42
Via: SIP/2.0/UDP proxy3.example.net;branch=z9hG4bK3s09ujnsnnen3
Record-Route: <sip:proxy1udp.example.net;lr>
Record-Route: <sips:proxy1tls.example.net;lr>
Record-Route: <sips:proxy2tls.example.net;lr>
Record-Route: <sip:proxy2sctp.example.net;lr>
Record-Route: <sip:proxy3sctp.example.net;lr>
Record-Route: <sip:proxy3udp.example.net;lr>

Note the double-record-route technique used by the proxies. For more information, see RFC 5658.

Now, these endpoints don’t need to be able to parse these tokens and addresses, at least not to the level of understanding their internal structure – they just need to be able to preserve them, following the requirements in the standards for including them in subsequent messages. This is where a few implementations ran into trouble – resulting in errors from failed parses of information they didn’t need in the first place. For instance, some IPv4-only endpoints assumed they would never see IPv6 addresses in the messages they received, so they dropped the incoming message above as malformed when parsing across the [2001:db8::2:1] address in the second Via header field value. These implementations didn’t really need to parse the value at all. They only need to reflect it, unchanged, in any response they send to the request. Following Postel’s Maxim in this case would result in higher levels of interoperability.

An earlier article went deeper into how RFC3263′s requirements provide for switching between transports like UDP, TCP, and SCTP at each hop. One thing that RFC doesn’t specify well is when to use IPv6 or IPv4 when both are available. As IPv6 becomes more available, dual-stack hosts (those able to use IPv6 and IPv4 at the same time) will encounter usability conditions that change over time. As a new IPv6 path is formed between endpoints, configuration and optimization changes may lead to IPv6 significantly outperforming IPv4 early in a given day, but not work as well (if at all) later that afternoon. How does a host choose which address family to use when it needs a new connection for a request?

Work is ongoing in the IETF to provide an algorithm answer that question. The current working document focuses on TCP and uses a weighting parameter, P, that affects what order the different address families are tried and how long to delay before trying the other family.

When P is 0, both families are tried simultaneously, each starting with the A or AAAA DNS lookup, followed by a TCP connection attempt. Whichever connects successfully first causes P to be adjusted in the direction that favors the quicker family. Positive values of P favor IPv6, negative favor IPv4. The size of the adjustments depend on the several factors, including whether the quickest family was the one currently favored.

When P is non-zero, the attempt to use the second family is delayed by 10*abs(P) milliseconds.

In all cases, when the attempts using both families succeed, the connection that was established first is kept. The subsequent connection is reset.

These ideas are still being refined – the current working draft anticipates that algorithm will be adjusted before it is proposed as a standard. For instance, there may need to be more clarity around which address family to issue the DNS queries over. There is also work proposed to specify what to do when the choices are richer than TCP over IPv6 vs. TCP over IPv4.

Due to the large growth in video over mobile networks, video optimization systems such as those from Bytemobile, Flash Networks, Ortiva, Vantrix, etc., have become popular for their ability to help control the growth of video-related bandwidth (examples include transcoding, buffer control, caching and so on).  Often, these systems are initially installed standalone to perform a static function for all traffic for all users on the network.  However, joining optimization systems with policy control adds a number of additional benefits:

• Selectively differentiate optimization based on subscriber tier—as tiers become more common, these tiers require the coordination of QoS, charging & quota treatment across multiple network elements including GGSN, DPI and other systems
• Selectively differentiate optimization based on roaming status—for example, a user (or his enterprise IT manager who may be paying the bill) may want very limited or no video at all when roaming
• Intelligently utilize adjunct functions commonly found in optimization boxes such as content filtering, http header insertion or redirection to notify the user of some service change, or use of  a self-care portal to let subscribers manage their own service choices

• Only utilize optimization resources when needed, minimizing the required investment in optimization capacity.  In particular, if the PCRF is provided with near-real time RAN Aware status data, optimization can be applied only when network is at risk of congestion or actually congested, minimizing resource requirements as well as any negative impact on a subscriber. This is particularly relevant in the case of RAN congestion.

• Re-use existing integration work to get subscriber, device, network and roaming status from the PCRF rather than requiring another integration project to re-deliver that data to the optimization system.

The most commonly used interface between the PCRF and an optimization system is based on 3GPP Gx, the interface originally designed between the PCRF and GGSN.  Since optimization systems have a number of functions not anticipated by 3GPP, this interface can use what are referred to as “pre-defined rules” in the Charging-Rule-Install portion of the 3GPP Gx specification to pass what are effectively proprietary commands.  Also, the systems need to make some adjustment to required and optional fields since the optimization box may or may not know mobile specific entities such as IMSI, MSISDN, IMEI, etc.

3GPP recently acknowledged the common use of Gx in this way with optimization systems, DPI and other non-GGSN devices, by defining a “Traffic Detection Function” or TDF in Release 11.  The TDF to PCRF reference point, listed as Sd, will have strong similarities to Gx while adapting to some of the unique natures of a non-GGSN device.  In other words, the spreading out of the mobile packet core is officially underway.

Given the current business climate, service providers are looking for every opportunity to maximize return on their technology investments and determine creative new strategies for focusing their valued labor resources on maintaining and evolving their technology investments over time. Tekelec Advantage Services offers a portfolio of value-added service offerings made up of consulting, integration, and assisted operation service products available for review today.

These new services have been developed to meet the following strategic objective: Implement a portfolio of high-value consulting, integration and assisted operation services that provide our Customers the expert knowledge and support required to maximize their return on investments by implementing solutions that fully utilize the power of Tekelec’s next-generation network technologies.

Services included in the new Tekelec Advantage Service Portfolio include:

Consulting Services

 - Policy business use case consulting 

 - Remote system assessment and analysis

- Network capacity analysis

- Network growth analysis

Integration Services

- Policy interoperability testing service

- Performance Intelligence Center KPI specification service

- PIC custom KPI report generation service

- Post cutover support service

Assisted Operation Services

- On-site/Remote engineering support

- PIC Preventative Maintenance Service

- 24/7 NOC Network Operation Center assisted operation

- Special event support coverage

- On-site software upgrade service

Benefits

• Reduces risk by assisting in planning new next-gen technologies in the customer network
•  Maximizes the return on the Tekelec next-gen technology investment by leveraging the full potential of Tekelec solutions within the customer’s network!
• Accelerates proof of the customer’s business case
• Ensures solution success with the right proactive expertise during adoption and OA&M knowledge transfer
• Provides flexibility and resource cost avoidance to support ongoing Tekelec system administration

For more information about Tekelec Advantage Services, please contact your Tekelec Account Manager.

Smartphones and tablet devices are selling like hotcakes and mobile Internet demand is through the roof. Unfortunately for operators, while mobile data traffic is exploding, revenue is not. To cope, they must both maximize efficiency to trim the bottom line and create new services to grow the top line.

Join Tekelec and Yankee Group at this webinar on April 21 to learn how Network Intelligence (NI) can help operators address this challenge. NI’s combination of managing session data, granular subscriber usage data and device information coupled with network performance management gives operators the insight, control and agility they desperately need.

Sign up today.

Last time, I mentioned that draft-ietf-simple-sessmatch, one of the few remaining milestones for SIMPLE, had some controversies associated with it. For the sake of brevity, I will refer to the extension described in that draft as “sessmatch.”

But before we get into the issues related to sessmatch, let’s discuss the problem it sets out to solve: Sessmatch is designed to make life easier for Session Border Controllers (SBCs) when handling MSRP. An SBC typically anchors media by rewriting the Session Description Protocol (SDP) to insert itself into the media stream. Each endpoint sees a media description that points to the SBC, rather than the peer endpoint. The SBC (hopefully transparently) relays media between the endpoints.

In the case of MSRP as defined in RFC 4975, this doesn’t work. The problem lies in the way an MSRP endpoint recognizes its peer. For example, Bob’s endpoint might send the following in an SDP answer to an offer from Alice:

a=path:msrp://bob.example.com:2855/asfd34;tcp

Alice opens a TCP connection to Bob, and sends an MSRP SEND request that contains the following URI in the To-Path header field:

msrp://bob.example.com:2855/asfd34;tcp

Bob’s endpoint knows this is Alice because it’s the URL he gave to Alice. (We assume Bob authenticated Alice in the signaling layer and used confidentiality protection.) The URI is designed to be hard to guess, so Mallory can’t easily send the same URI and pretend to be Alice. You can think of the URI as a shared secret between Alice and Bob.

But if there’s an SBC between Bob and Alice, the SBC has to rewrite the SDP in order to anchor the MSRP session. So Bob’s SDP answer gets changed to something like this:

a=path:msrp://sbc.example.com:2855/asfd34;tcp

Alice now opens a connection towards the SBC. Let’s assume for the moment the SBC then opens a connection toward Bob and relays packets from Alice to Bob. (The actual direction of connections may be more complicated if COMEDIA is used–but let’s ignore that for now.) The problem is, Alice now sends the following in the MSRP To-Path header field:

msrp://sbc.example.com:2855/asfd34;tcp

Bob doesn’t recognize that URI as the one he sent to Alice, so the session fails. The SBC could have kept state about the URI mapping, and rewritten the To-Path headers field value to match Bob’s expectation. But SBCs are usually large-scale devices, and this bit of work adds up to a lot over many simultaneous sessions. This is further complicated by the fact that many SBCs handle packet relaying in special purpose hardware. They quickly lose the hardware advantage when they have to apply a lot of processing to the relayed packets.

The sessmatch extension tries to mitigate this, using the fact that the only really hard-to-guess part of an MSRP URI is the session identifier. For example, Bob’s URI:

msrp://bob.example.com:2855/asfd34;tcp

… has a session identifier of “asfd34″. MSRP requires that identifier to be unique and hard to guess. The rest of the URI (the address, port, and transport) is actually pretty easy to guess. So if we treat “asfd34″ as the shared secret, that’s close to the same level of secrecy as you get with the whole URI. So if Bob supports the sessmatch extension, he doesn’t insist that Alice hands him the exact URI as he sent in the SDP answer. He only insists that the session id part is the same. The SDP rewrites the SDP to contain the following URI:

msrp://sbc.example.com:2855/asfd34;tcp

But since that URI contains the exact same session ID as Bob’s original URI, Bob can still use it to determine he’s really talking to Alice.

The apparent great thing about sessmatch is that this is backwards compatible with RFC 4975, in the case where no SBCs are present. If nothing rewrites the SDP offer or answer, then Alice still sends Bob’s original URI. This matches both under the original RFC 4975 matching rules and the sessmatch extension matching rules.

Unfortunately, when an SBC is present, there are some cases where this backwards compatibility breaks down. And these are real world cases that have been encountered by real-world implementors. I’ll present the details in my next post.

By Matt McCann, Principal Architect

The Diameter protocol is widely used in 3G, IMS and LTE architectures to transport policy, charging, authentication and mobility management messages – traffic that will rapidly rise as mobile data usage increases.

To best manage the growth of Diameter traffic, operators are examining how to create a separate Diameter signaling infrastructure at the network core. The goal is to facilitate signaling between network elements, eliminating a mesh-like architecture of direct connections between endpoints such as mobility management entities (MMEs) and home subscriber servers (HSSs). This would relieve endpoints of handling all session-related tasks such as routing, load balancing, congestion control and failover management.

Initially, implementing an IMS or LTE network without a signaling core may be sufficient, but as traffic levels grow, the lack of a capable signaling infrastructure poses a number of challenges, including:

• Scalability: Each endpoint must maintain a separate SCTP association with each of its Diameter peers as well as the status of each, placing a heavy burden on the endpoints as the number of nodes grows.
• Congestion control: Diameter lacks the well-defined congestion control mechanisms found in other protocols such as SS7.
• Protocol mediation: Vendors are likely to use their own variants of the Diameter protocol based on how they believe a specific interface should be implemented. This implementation can vary slightly from those of another vendor, creating potential interworking issues when multi-vendor equipment is combined in one network, a common approach for operators that take a best-of-breed approach.
• Network interconnect: A fully meshed network is completely unworkable when dealing with connections to other networks because there is no central interconnect point. This also exposes the operator’s network topology to other operators and can lead to security breaches.
• Interoperability testing (IOT): Protocol interworking becomes unmanageable as the number of devices supplied by multiple vendors increases. With no separate signaling or session framework, IOTs must be performed at every existing node when a new node or software load is placed in service.
• Support for both SCTP- and transmission control protocol (TCP)-based implementations: SCTP-based elements cannot communicate with TCP-based elements unless they are upgraded or all of the elements support both protocol stacks.
• Subscriber to HSS mapping: When there are multiple HSSs in the network, subscribers may be homed on different HSSs. Therefore, there must be some function in the network that maps subscriber identities to HSSs.
• Policy and charging rules function (PCRF) binding: When networks require multiple PCRFs, operators must have a way to ensure that all messages and sessions associated with a particular user are processed by the same PCRF.

Centralizing Diameter routing creates a signaling architecture that reduces the cost and complexity of the core network and enables core networks to grow incrementally to support increasing service and traffic demands. It also facilitates network monitoring by providing a centralized vantage point in the signaling network. A centralized Diameter router is also the ideal place to add other advanced network functionalities like address resolution, Diameter interworking and traffic (roaming) steering.

The last time I posted, we explored the situation surrounding IPv4 address exhaustion. This time, we’re going to look at some of the implications of that shortage.

One approach to addressing the shortage that has been bandied around is the use of what is called “Carrier Grade Network Address Translators (CG-NATs).” The idea behind these CG-NATs is that ISPs would assign all of their users un-routable IP addresses in a private network. The CG-NAT would operate similar to consumer NATs, opening and closing ports as customers send traffic to and from the network.

The major difference between CG-NATs and consumer NATs is that end users have no control over the policy of these CG-NATs. Consumer NATs typically allow applications to automatically open and close specific ports (critical for many multiplayer games) using uPNP, IGD, or NAT-PMP; and they allow users to specify port forwarding rules manually (to enable Slingboxes, certain types of VoIP applications, etc).

So, what happens when these CG-NATs start popping up between users and the Internet? Well, a lot of stuff breaks. To be fair, the most popular applications – web browsing, email, and most instant messaging clients – will continue to work just fine. But real-time applications? They won’t fare as well. And many VPN technologies – in particular, those based on IPSec – have no hope of working at all.

To add insult to this injury, most users already have NATs deployed in their home networks (often supplied by the ISP itself), which means that deployment of CG-NATs will now put them behind two NATs. And several techniques that applications can use to successfully traverse a single NAT start to break down when multiple NATs are in the way.

But CG-NATs aren’t the only way to stretch the existing IPv4 address pool a little bit. There’s an alternate proposal being put forward by an individual in the IETF, which would effectively issue a fraction of an IP address to each customer. The basic idea is that users’ equipment would receive an IP address and a valid range of TCP and UDP ports that they are allowed to use.  It’s an imperfect solution, to be sure (for example: who gets the high-value ports, like 21, 25, 80, 443, and 993?), but at least it avoids some of the problems that are intractable in CG-NAT scenarios.

It is also predictable that the actual economic value of an IP address will increase. An exchange market in IP addresses – whether a black market or an RIR-facilitated swap – is almost inevitable. Of course, this means that anyone requiring a whole IP address to themselves (for example, to run a web server or an IP PBX) will start paying increasingly stiff fees to continue to use that address.

Hosting just about any service requires the use of key ports on an IP address (e.g., ports 80 and 443 for web sites), so doing so requires one of these “whole IP addresses” that will be going up in price. And it’s not too hard to predict that, as the cost of hosting content goes up, the number of content sources that can afford to make information available will start going down. It will have a distinctly un-democratizing effect on the Internet at large.

Finally, the introduction of CG-NATs – if that is the path carriers take – requires additional hardware, leading to increases in both capital and operational expenses. The introduction of another choke point in the network means that the network becomes increasingly brittle and breaks more often, leading to increased customer service calls, and decreased customer satisfaction.

So, while it’s not the end of the network as we know it, life after address exhaustion will be far worse for users, application providers, and even carriers.

But perhaps it’s not as bleak as things sound. There is a far better solution to the address shortage. I’ll discuss that next time.

Be sure to check our Website this week. We’ve revamped the site to have a more engaging and dynamic look, as well as provide better usability. As you will see, the site’s content is now organized so it is more focused on solutions that address key service provider challenges, such as managing network costs, accelerating roll out of new personalized services and managing the exploding consumer bandwidth demand.

Take a few minutes to check out the site. As always, let us know your thoughts on the new look!