Provider-Managed IRON
draft-templin-iron-pm-01.txt

Abstract

The Internet Routing Overlay Network (IRON) is a new internetworking architecture based on encapsulation of inner network layer packets within outer network layer headers using a non-broadcast, multiple access (NBMA) virtual interface model. IRON suggests a third-party global deployment of servers and relays to achieve a Provider-Independent (PI) routing and addressing framework, but there may be instances in which an Internet Service Provider (ISP) wishes to manage its own IRON deployment. This document presents a Provider-Managed IRON framework that offers a fast path alternative for deployment of a long term solution.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

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."

This Internet-Draft will expire on November 24, 2011.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Table of Contents

• 1. Introduction
• 2. IRON Conceptual Model
• 3. Provider-Managed IRON
• 4. Dealing with NATs
• 5. Dealing with Mobility
• 6. IANA Considerations
• 7. Security Considerations
• 8. Acknowledgements
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Author's Address

1. Introduction

The Internet Routing Overlay Network (IRON) [RFC6179] is a new internetworking architecture based on encapsulation of inner network layer packets within outer network layer headers using a non-broadcast, multiple access (NBMA) virtual interface model. IRON suggests a third-party global deployment of servers and relays to achieve a Provider-Independent (PI) routing and addressing framework, but there may be instances in which an Internet Service Provider (ISP) wishes to manage its own Provider-Managed IRON deployment.

By managing its own IRON deployment, an ISP can ensure optimal placement of servers and relays so that clients receive a high quality of service with minimal routing path stretch. The ISP can further delegate native IP prefixes to clients even if they are located behind one or several layers of NATs, and even if they move between different network points of attachment. Since most ISPs service limited regional areas, however, routing stretch may become significant for mobile users that travel far from their homes (e.g., to a different continent). This situation is no different than that for corporate travelers who establish Virtual Private Network (VPN) links to their home enterprise networks when they travel abroad, and can be mitigated by ISP placement of minimal support infrastructure outside of their primary coverage region.

This document presents a Provider-Managed IRON framework, and shows that it can offer ISPs a fast path alternative for deployment of a long term solution.

2. IRON Conceptual Model

IRON is descended from the RANGER architecture [RFC5720][RFC6139]; it uses Virtual Enterprise Traversal (VET) [I-D.templin-intarea-vet] and the Subnetwork Encapsulation and Adaptation Layer (SEAL) [I-D.templin-intarea-seal] as its functional building blocks. IRON uses the VET NBMA virtual interface model for coordination between neighboring routers on a virtual overlay network. It also uses SEAL as an IP-in-IP encapsulation sublayer, and uses the SEAL Control Message Protocol (SCMP) for signaling between tunnel endpoints. In particular, IRON clients use SEAL and SCMP to establish bidirectional tunnels with IRON servers and to inform the servers of any outer network layer address changes. IRON clients can also establish unidirectional tunnels to servers that are closer to the final destination based on route optimization signaling.

IRON clients connect End User Networks (EUNs) which are assigned EUN prefixes (EPs) taken from highly-aggregated IP prefixes known as Virtual Prefixes (VPs). IRON servers connect their clients to a virtual overlay network configured over an internetwork such as the global Internet. IRON relays in turn connect the virtual overlay network to the native (i.e., non-IRON) Internet. The IRON relays in the virtual overlay network belong to a single Autonomous System (AS) and use eBGP to advertise the VPs externally into the native Internet default-free routing system. IRON relays and servers further use an interior routing protocol such as iBGP to track the EPs assigned to clients.

To provide better service to clients, sufficient numbers of IRON relays and servers should be uniformly distributed throughout the internetwork over which the virtual overlay network is configured. Since the number of IRON servers needed may be very large, each server is required only to keep track of its own set of clients and to convey its client constituency to each of the relays. The iBGP peerings between servers and relays is therefore arranged as a partial mesh in which servers report their client constituencies to each relay but not to other servers. In this arrangement, servers have partial topology information and relays have full topology information. Routing within the virtual overlay network may therefore direct the initial packets in a flow through a suboptimal path that involves extraneous relays and servers as intermediate hops, but redirect messages will quickly inform the client of a better route.

Figure 1 below depicts an example Provider-Managed IRON deployment:

                                  .-.
                               ,-(  _)-.
                            .-(_    (_  )-.   +--------+
                           (_  Internet    )--| Host(C)|
                              `-(______)-'    +--------+
                                   |
                            +------------+
            ________________|    Relay   |________________
         .-(                +------+-----+                )-.
      .-(                    ^^    |   ||                     )-.
    .(                       ||    |   vv                       ).
  .(              +------------+   |  +------------+              ).
 (      +========>| Server(A)  |<--+  | Server(B)  |=======+        )
(       ||        +------------+      +------------+      ||         )
(       ||                                                vv         )
 ( +-----------+                                       +-----------+ )
   | Client(A) |                                       | Client(B) |
   +-----+-----+              ISP Network              +-----+-----+
         |    (                                          )   |
        .-.     .-(                                 .-)     .-.
     ,-(  _)-.      .-(_________________________)-.      ,-(  _)-.
  .-(_    (_  )-.                                     .-(_    (_  )-.
 (_  IRON EUN(A) )                                  (_  IRON EUN(B) )
    `-(______)-'                                       `-(______)-'
         |                                                  |
     +---+----+                                         +---+----+
     | Host(A)|                                         | Host(B)|
     +--------+                                         +--------+

1. From Host(A) in IRON EUN A to Host(B) in IRON EUN B (depicted in Figure 1)
2. From Host(A) in IRON EUN A to Host(C) in the Internet
3. From Host(C) in the Internet to Host(A) in IRON EUN A

In case 1, the initial packets in the flow sourced from Host(A) are forwarded through EUN(A) to Client(A), which then forwards them via the bidirectional tunnel to Server (A). Server(A) then forwards the packets to a Relay, which returns redirect messages and tunnels the packets further to Server(B). Server(B) then forwards the packets via the bidirectional tunnel to Client(B), where they are forwarded across EUN(B) and delivered to Host B. Following the redirect messages, subsequent packets flow directly via a unidirectional tunnel from Client(A) to Server(B) with the Relay and Server(A) removed from the path.

In case 2, packets sourced from Host(A) are forwarded through EUN(A) to Client(A), which forwards them via the bidirectional tunnel to Server(A). Server(A) then forwards them to a Relay, which in turn forwards them via normal Internet routing until they reach host C.

In case 3, packets sourced from host C are forwarded through normal Internet routing until they reach a Relay that connects the Provider-Managed virtual overlay network to the rest of the Internet. The Relay then forwards the packets to Server(A), where they are forwarded through the bidirectional tunnel to Client(A) then delivered to Host(A).

These fundamental communication flow archetypes apply to the case of IRON virtual overlay networks configured over the unbounded global Internet when a third party supplies EUNs with PI prefixes. However, the same archetypes apply when the virtual overlay network is configured over a more limited topology such as an ISP's service network where the IP prefixes assigned to EUNs are Provider-Managed. The following section discusses a Provider-Managed IRON model.

3. Provider-Managed IRON

The generic IRON use case assumes that the internetwork over which IRON overlay networks will be configured is the Internet itself. In other words, the generic use case assumes a global deployment of relays and servers by a third-party agency that does not coordinate with any specific ISPs. In that case, the VPs/EPs served by the third party would be independent of any Provider-Managed prefix space, and hence would be PI. However, an ISP wishing to roll out a useful service for its customers could choose to establish an IRON deployment using its own service network as the internetwork over which the virtual overlay is configured. In that case, the VPs/EPs serviced by the ISP would be Provider-Managed and there would be no third-party agencies for customers to coordinate with. The ISP would also be in the best position to provide optimal or nearly-optimal placement of IRON relays and servers within its managed network.

When an ISP deploys its own IRON virtual overlay system, it establishes relays at the border of the virtual overlay network that connect the overlay to the global Internet. These relays run eBGP on their Internet-facing interfaces, and advertise the VPs that have been delegated to the ISP. The ISP should only need to advertise a small number of VPs that would only very rarely need to be withdrawn and re-announced within the global routing system. The ISP also deploys servers close to its customer EUNs in sufficient numbers so that the customers receive a high quality of service. While the IRON architecture allows for the relay and server function to be deployed on the same physical platform, for reasons of scaling it is expected that they will often be deployed on separate platforms.

In terms of scaling, in the limiting case in which all of the ISP's IRON routers provide both the relay and server function, the relay/servers would engage in a full mesh iBGP session the same as described in the Softwire Mesh Framework [RFC5565]. However, a full mesh framework would present a limiting factor for scaling in multiple dimensions.

First, each relay/server would only be able to service a limited set of customer client EUNs, since each client requires that the server maintain bidirectional tunnel state and engage in periodic keepalive exchanges. Second, since an ISP wishing to support a large number of customer clients would need to deploy a large number of relay/servers, the number of iBGP peering sessions between them would grow with the square of the number of relay/servers. This scaling situation can be addressed through the use of route reflectors, but the route reflectors cannot convey reachability state from one relay/server to another. Moreover, there is no reason that each server needs to have full knowledge of all EPs assigned to all customer EUNs. Instead, it should only have to know about the EPs assigned to its own current set of client customers and maintain a default route pointing to the relay router anycast address.

Hence, when the server and relay functions are deployed on separate platforms, the IRON system enables a "partial mesh" topology in which servers report only the EP-to-client relationships for all of their client customers and maintain default routes to relays. Relays in turn discover all EP-to-server relationships and thus have full topology knowledge of the EP distributions throughout the ISP network. Moreover, servers can be placed close to the customers to support optimal routes, and more servers can be added as the client load grows.

As an example, assume that an ISP deploys a Provider-Managed IRON deployment using a single IPv6 ::/24 VP, from which it assigns IPv6 ::/56 EPs to its client customers. The ISP can establish a reasonable number of relays (e.g., 100) at the virtual overlay network border with the Internet. The ISP could then uniformly distribute a sufficient number of servers (e.g., 2^16) located close to customers throughout its network, where each server would be sized to serve 2^16 customers. Such a deployment would enable service for all 2^32 ::/56 EPs taken from the single ::/24 VP while advertising only a single VP into the global routing system. Each of the 100 relays would need to maintain iBGP peering sessions with each of the 2^16 servers to discover all client-to-server mappings in the IRON system. Each of the 2^16 servers would only need to report their client constituency via the 100 iBGP peering sessions and would not need to discover the client constituencies of other servers since they only require the relay router anycast address as the default route.

Since the servers would have only partial topology information (i.e., they would only know about their own clients and about the relay anycast default route) packets originated by one of their clients A and destined to a client B that is serviced by a different server would need to be forwarded through a relay. Using the IRON secure redirection system, however, the relay would return a redirect message which the server would forward to the client customer. Thereafter, packets originating from client A and destined to client B would be forwarded directly to client B's server without involving either client A's server nor any relays. This technique is often known as route optimization, and is a fundamental requirement for any production-quality routing system.

4. Dealing with NATs

In typical ISP deployments, customer EUNs are located behind Customer Premises Equipment (CPE) routers that perform a Network Address Translation (NAT) function internally. With the impending runout of IPv4 addresses, ISPs are now also faced with a situation in which they may need to assign private-use IP addresses to the outward-facing interfaces of CPEs and perform a second level of NATing withing the ISP network. Hence, devices in customer EUNs will be located behind one or several layers of NATs which impart special requirements on tunneling technologies. In particular, tunneling technologies will need to be configured over the UDP protocol which can traverse NATs.

In the 6a44 proposal [I-D.despres-softwire-6a44], the authors present a novel method of supporting IPv6 clients in EUNs through stateless coordinations with servers in the ISP network. Each client in this model receives only a single address that is constructed based on the outer NAT address and port mapping values, however, and these values can change across NAT reboots and/or loss of state. Hence, it may not be practical for administrators to represent the 6a44 addresses in a static name resolution system such as the DNS and/or for communicating peers to rely on a stable address for session continuity.

Using the Provider-Managed IRON approach and its constituent SEAL mechanism, however, a client device in the customer EUN can receive an EP from its service provider (e.g., an IPv6 ::/56) and then register this EP with a nearby server that it discovers through an anycast router solicitation. Once registered, the server distributes this new EP registration to all relays.

This stateful registration establishes next hop information in the server which the client must refresh periodically by sending beacons which have the side effect of keeping state alive in any NATs on the path. Since NATs may lose state and create new mappings, however, the server does not rely on the IP address and port mapping information to identify the client. Instead it relies on the SEAL identification tags that were established when the client first registered with the server. In this arrangement, it does not matter if the address and port mappings change periodically as long as the client sends beacons frequently enough to keep the NAT state synchronized with the server state.

5. Dealing with Mobility

When a client moves to a new network point of attachment, it simply sends a new anycast router solicitation message to register with a new server. Unlike the global IRON case, however, a client in a Provider-Managed IRON deployment can only discover a server in its home ISP even if it has moved far away from home. For example, if a customer from ISP A located in the United States takes their IRON client router to Beijing they can still continue to use their Provider-Managed EPs, but all traffic to and from the EPs would need to be routed through the relays and servers in the ISP A US-based network even if both correspondent hosts are located in Beijing. Although clearly not optimal, this situation is no different than for a corporate employee who takes their laptop to a distant country and uses a VPN to connect to their home office.

However, if ISP A wishes to provide better mobility service to its customers, it can deploy additional relays and servers in the networks of other ISPs worldwide simply by leasing public IP addresses and establishing equipment in the foreign ISPs networks. In that case, the Provider-Managed IRON case begins to look identical to the Provider-Independent case, and mobile clients can achieve a high quality of service even if they have moved far away from their home network. It therefore becomes immaterial as to whether the customer would pay an ISP for their IRON services or pay some third party entity - the service they would receive would be equivalent and dependent only on the quality of the IRON deployment.

6. IANA Considerations

There are no IANA considerations for this document.

7. Security Considerations

The security considerations in IRON [RFC6179] apply also to this document.

8. Acknowledgements

The concept of a Provider-Specific version of IRON was inspired by discussions in the intarea working group during IETF79. The ideas were further motivated by related works authored by Brian Carpenter, Remi Despres and Sheng Jiang.

9. References

9.1. Normative References

9.2. Informative References

Author's Address