Service tunnel over a connectionless network

A method for establishing a service tunnel for private internet protocol services over a connectionless network. The private internet protocol services are transported over the service tunnel in accordance with selected respective private internet protocol services.

FIELD OF THE INVENTION

The present invention pertains to the field of internet protocol (IP) networks. More particularly, the invention relates to a service tunnel for private IP services over a connectionless network.

BACKGROUND OF THE INVENTION

Enterprises with remote sites, such as corporations, consulting firms, and law firms, have typically formed wide area networks (“WANs”) using frame relay networks or time division multiplexing (“TDM”) leased lines. Some larger enterprises have formed WANs using asynchronous transfer mode (“ATM”) networks. Those enterprise WANs over the connection-oriented frame relay, TDM, and ATM networking technologies typically provide connectivity between computers in the various enterprise sites, reachability among users in the sites, guaranteed quality of service, priority schemes regarding communications, and relatively good security for data and addresses.

In contrast to the enterprise-oriented connection-oriented networking technologies with centralized control is the Internet, which has exploded in popularity in recent years. The Internet is a loose collection of networks organized into a multilevel hierarchy using a wide variety of interconnection technologies. The Internet is a connectionless datagram switching scheme bound together by addressing, routing, and IP but with decentralized control. Rather than focusing on enterprise communications, the Internet is focused on global packet transport, which involves the forwarding of packets. The Internet is widely used for accessing the World-Wide Web and for global email, but has generally been deficient with respect to certain communications services valued by enterprises, such as security, connectivity, and quality of service.

Because of the widespread use of different kinds of wide-area network technologies, such as frame relay, ATM, TDM, and IP, network providers have had to build and maintain several different networks to satisfy the needs of network users, such as individuals and enterprises. This has been very expensive. Moreover, enterprises have had to pay high fees to use the connection-oriented WAN technologies in order to get the level of service demanded by those enterprises.

Attempts have been made to make the Internet more enterprise friendly. For example, a virtual private network (“VPN”) with an IP backbone is described inBGP/MPLS VPNsby E. Rosen and Y. Rekhter, Request for Proposal (“RFC”) 2547, Network Working Group, Internet Engineering Task Force (“IETF”) (March 1999) (“RFC 2547”). A VPN is an IP connection between two sites over a public IP network that has its payload traffic encrypted so that only the source and destination can decrypt the traffic packets. The RFC 2547 document discloses using multiprotocol label switching (“MPLS”) for forwarding packets over the background and using border gateway protocol (“BGP”) for distributing routes over the backbone. Although RFC 2547 briefly suggests some quality of service techniques, the focus of RFC 2547 is on the transport of packets. Moreover, the VPN scheme described in RFC 2547 is a transport tunnel that starts at the network side, rather than a scheme that starts at the end-user's side.

Another attempt to make the Internet more enterprise friendly is the layer two tunneling protocol (“L2TP”) described inLayer Two Tunneling Protocol “L2TP” by W. Townsley et al., RFC 2661, Network Working Group, IETF (August 1999) (“RFC 2661”). The RFC 2661 document discloses a scheme for facilitating the tunneling (i.e., encapsulating) of point-to-point protocol (“PPP”) packets across an intervening network in a way that is as transparent as possible to both end-users and applications. Although RFC 2661 describes a scheme that starts at the end-user's side, the focus of RFC 2661 is PPP and the transport of packets.

SUMMARY OF THE INVENTION

A method is described for establishing a service tunnel for private internet protocol services over a connectionless network. The private internet protocol services are transported over the service tunnel in accordance with selected respective private internet protocol services.

DETAILED DESCRIPTION

A method is described for establishing a service tunnel for private internet protocol (IP) services over a connectionless network. The service tunnel allows the encapsulation and transport of private IP packets containing data, voice, and video information over an intervening connectionless network between end-users and the providing of enterprise services to end-users. For one embodiment, the services provided by the service tunnel include connectivity, addressing, reachability, forwarding, peering, and premium services, such as priority and quality of service.

As described in more detail below, for one embodiment the service tunnel is a modified layer two tunneling protocol (“L2TP”) tunnel and the connectionless network is an IP network. For an alternative embodiment, the connectionless network is a multiprotocol label switching (“MPLS”) network.

FIG. 1illustrates the layered network architecture for one embodiment of the present invention. Layer 1 includes the long haul portion10and the local metropolitan sections8and9. For one embodiment, the long haul portion10and the metropolitan sections8and9comprise an optical network between network carriers.

Layer 1 is the network interface layer. Layer 1 connects a host to the local network hardware. Layer 1 makes a connection to the physical medium. Layer 1 uses a specific protocol for accessing the medium. Layer 1 also places data into frames. Layer 1, however, does not provide enterprise services to end-users.

Layer 1 shown inFIG. 1includes the physical and data link layers of the Open System Interconnect (“OSI”) reference model developed by the International Organization for Standards (“ISO”).

Layer 3 shown inFIG. 1is the Internet protocol network layer, which for one embodiment is also the service layer. In other words, in addition to being the Internet protocol layer, layer 3 provides the enterprise services to end-users. The enterprise services are also referred to as subscriber services or just services.

Layer 3 is where the Internet protocol is found. Layer 3 transfers user messages from source host to destination host. Layer 3 is a connectionless datagram service. In layer 3, root selection is based on some metric. Layer 3 uses IP addresses as a road map to locate a host. Layer 3 relies on routers or switches. Layer 3 includes the Internet control message protocol (“ICMP”), which uses an IP datagram to carry message about the state of the communications environment.

For one embodiment, layer 3 also includes a service tunnel for providing subscriber services to end-users. The service tunnel is a modified L2TP tunnel. For one embodiment, the subscriber services are offered using layer 3 without the use of connection-oriented technologies such as frame relay, TDM, and ATM. An intended advantage of the service tunnel is to help to reduce the expenses of network providers by helping to reduce the number of networks needed to be built and maintained. An another intended advantage of the service tunnel is to reduce or eliminate the high fees otherwise required by connection-oriented WAN technologies.

The service tunnel found in layer 3 provides services for layers higher than layer 3 in addition to services for layer 3. For example, the service tunnel also provides services for the IP layer 3, the transport layer four and the application layer five (not shown). The transport layer four includes the transmission control protocol (“TCP”) and the user datagram protocol (“UDP”). Under the OSI model, the service tunnel provides services for the network layer, the transport layer, the session layer, the presentation layer, and the application layer. The layers 3 and above are also referred to as layers 3 plus.

For an alternative embodiment, layer 3 contains MPLS. MPLS is a connectionless optimized switching technology for IP networks. MPLS involves prepending IP packets with a routing label at an edge of an “MPLS cloud” and performing all forwarding within the cloud based on the label value. For that alternative embodiment, the service tunnel found in layer 3 would run over MPLS. That service tunnel would provide services for layers 3 plus.

FIG. 2illustrates a network configuration11for implementing an embodiment of the present invention. The public IP network12includes virtual routers21,22, and23. Virtual routers21–23provide access to the global Internet, including access to the World Wide Web. Virtual routers21–23thus use IP protocol.

For an alternative embodiment, network12is an MPLS network. For that alternative embodiment, virtual routers21–23would use MPLS protocol in addition to IP protocol.

For one embodiment, customer premises (“CP”) routers14,15, and16are at various sites of a single enterprise. For one embodiment, customer premises router14is coupled to virtual router21via a local area network (“LAN”) or a wide area network (“WAN”). Customer premises router15is coupled to virtual router22via a LAN or WAN. Customer premises router16is coupled to virtual router23via LAN or WAN.

FIG. 2also illustrates service tunnels30,31, and32. Service tunnel30is between virtual router21and virtual router22. Service tunnel31is between virtual router22and virtual router23. Service tunnel32is between virtual router21and virtual router23. Even though each service tunnel is established between two virtual routers, from the point of view of the end users (i.e., subscribers) at each of the customer premises routers14–16, each service tunnel appears to start from the end-user side, not the network side. This is because the service tunnel provides services to the end users. This contrasts with a transport tunnel, such as MPLS, that starts at the network side.

FIG. 2shows three CP routers, three virtual routers, and three service tunnels. For other embodiments of the invention any other number of CP routers, virtual routers, and service tunnels can be used. Moreover, more than one service tunnel can exist between two virtual routers.

Each of the service tunnels30–32facilities the tunneling of private IP packets across intervening network12in a way that is as transparent as possible to the customer premises routers and the applications running on those customer premises routers. Service tunnels30–32allow the formation of IP virtual private networks that offer services to subscribers at the CP routers14–16. Service tunnel30allows the subscriber at customer premises router14to send private IP packets over network12and have them transported to customer premises router15. Likewise, service tunnel30allows the subscriber at customer premises router15to send private IP packets to customer premises router14. Service tunnel31allows the subscribers at CP routers15and16to exchange private IP packets. Service tunnel32allows the subscribers at CP routers14and16to exchange private IP packets. The private IP packets sent by CP routers14–16over service tunnels30–32can contain data, voice, and video. Each of the service tunnels30–32allows sessions to carry different payloads within the same service tunnel.

The L2TP tunnel described in the RFC 2661 document provides a standard method for tunneling point-to-point protocol (“PPP”) packets. Service tunnels30–32are each a modified L2TP tunnel. The service tunnels30–32each include an extension to L2TP that provides a mechanism to support tunneling of additional payload types over individual sessions within an L2TP tunnel. These extensions provide added functionality that is optional and preserve backwards compatibility.

The service tunnels30–32each provide subscriber services (also called enterpriser services) to end users. The subscriber services include connectivity services, addressing services, reachability services, forwarding services, peering services, and premium services.

The connectivity services allow an end user to connect to all other sites within the subscriber's virtual private network. The connectivity services do not, however, allow an end user to connect to another subscriber's network.

Reachability services allow others within the same virtual private network to reach a particular end user. End users are able to advertise their respective addresses. Forwarding services allow an end user to decide how he or she would like to forward packets.

Premium services include policies on the priority of packets and the quality of services. Priority is also referred to as class of service (“CoS”). Class of service allows data to be tagged with a specific priority level with respect to the transport through service tunnels30–32. For example, CP router14can assign a delivery priority to its outgoing private IP packets to be forwarded through service tunnel30. This is important because during periods of congestion you do not want voice or video data sets to be dropped by switches or routers. A high priority assignment to these data sets ensures their delivery. Class of service enables “real-time” packets (for example, packets carrying full-motion video data) to be sent at a constant rate without interruption of delivery.

Data prioritization is only part of the equation, however. The delivery of time sensitive data also requires that sufficient bandwidth be available over service tunnels30–32and that transmission delays (i.e., latency) over service tunnels30–32be predictable and guaranteed. This is what quality of service is about. Quality of service (“QoS”) refers to parameters associated with data prioritization that specify such things as the amount of bandwith a priority data transmission over service tunnels30–32requires as well as the maximum amount of latency the transmission can tolerate in order for the transmission to be meaningful. Quality of service is important for transmitting real-time voice and video traffic. For example, a video conferencing application might receive a high priority tag that requires a certain amount of bandwidth, a specific transmission rate, and maximum latency.

Addressing services relate to the use of private addresses over the service tunnels30–32. The addressing services provided by service tunnels30–32include the hiding of the addressing scheme used by one enterprise from the general users of the public network12. In other words, the addressing services provide security with respect to the addresses. The private IP packet addresses of the individual end users of the enterprise are hidden when the packets are transported over the service tunnels30–32over the network12. The private IP addresses can be registered addresses, even though they remain hidden from others outside of the enterprise virtual private network.

The service tunnels30–32also provide security for the data transmitted by the private IP packets. The private IP packets can be encrypted so that they remain hidden from others outside of the enterprise virtual private network.

The peering services provided by the service tunnels30–32allow the sending of applications between clients, servers, and other computers within the enterprise over the service tunnels30–32.

Each of the service tunnels30–32is established by two virtual routers communicating with each other. For example, service tunnel30is established by virtual router21establishing a service tunnel between virtual router21and virtual router22.

Each of the service tunnels30–32is bidirectional, which means that private IP packets can be sent in each direction. Each of the service tunnels30–32is also symmetric.

When a service tunnel such as service tunnel30is set up, the end user specifies the Service Type. For the IP service tunnel that has been described herein, the Service Type is IP. For alternative embodiments, service tunnels are possible for other switching technologies, such as, ATM, TDM, or frame relay.

When a service tunnel is established, the service template is also specified. The service template refers to a class of service (i.e., priority), a quality of service, or other attributes, such as jitter requirements and the level of security. If, for example, high security is specified, then the data in the private IP packets would be encrypted.

Each of the service tunnels30–32may serve multiple subscribers or customers. In other words, for example, service tunnel30may serve enterprises A, B, and C concurrently. The virtual routers may also serve multiple customers. For example, virtual router21may serve enterprises A, B, and C. As another example, virtual router22may serve enterprises A, B, and D.

When a service tunnel is established, the end user indicates whether or not multiple enterprises will be using the specific service tunnel. For example, a particular enterprise may decide to pay a premium price to have a service tunnel, such as service tunnel30, dedicated to that particular enterprise without sharing that service tunnel without any other enterprises. If an enterprise does not request that the service tunnel be dedicated to that particular enterprise exclusively, the service tunnel can serve multiple enterprises. Each of the service tunnels30–32supports multiple virtual private network sessions. An enterprise CP router, such as CP router14, maps to the enterprise session within the tunnel.

FIG. 3illustrates the protocol structure for each of the service tunnels30–32. Each service tunnel uses two types of messages—namely, control messages48and data messages46. Control messages48are used in the establishment, maintenance, and clearing (i.e., tearing down) of tunnels and service tunnel sessions. Data messages46are used to encapsulate encapsulation services packets50and private IP packets52carried over the service tunnel. Encapsulation services packets50in turn encapsulate private IP packets52. Each of the service tunnels30–32is a modified L2TP tunnel, so the control messages48are modified L2TP control messages and the data messages46are modified L2TP data messages.

Control messages48use a reliable control channel44within L2TP to guarantee delivery. The fact that the control channel44is reliable means that the control channel44utilizes an acknowledgment mechanism.

The data messages46use an unreliable data channel42within L2TP for delivery. The fact that the data channel42is unreliable means that there is no acknowledgment of the receipt of data from the receiving node to the sending node. Data messages46are not retransmitted when packet loss occurs.

Private IP packets52are passed over L2TP data channel42encapsulated in encapsulated services packets50, further encapsulated in L2TP data messages46(within L2TP header), and yet further encapsulated in packet transport layer 4, such as UDP. For an alternative embodiment, packet transport layer 4 is TCP. Control messages48are sent over L2TP control channel44that transmits packets in-band over the same packet transport layer 4. The packet transport layer 4 overlays the IP network 3. Thus, the information in the packet transport layer 4 is in turn sent over the internet protocol layer 3.

Sequence numbers are required to be present in all control messages48and are used to provide reliable delivery on the control channel44. Data messages46may use sequence numbers to reuse packets and detect lost packets.

All values are placed into their respective fields and sent in network order, which is high order octets first.

FIG. 4illustrates the service tunnel L2TP packet60, which includes an L2TP header62and a payload portion96. The payload96contains either control messages38or data messages46. The data messages46in turn contain encapsulation services packets50and private IP packets52. The service tunnel L2TP packets60for the control channel44and the data channel42share a common header format62.

The fields of header62are as follows.

The Type (“T”) bit65of L2TP header62indicates the type of message. Bit65is set to zero for a data message46and set to one for a control message48. If the Length (“L”) bit66is set to one, the Length Field82is present. The bit66must be set to the number one for control messages48. The X bits67,69, and72are reserved for future extensions. If the Sequence (“S”) bit68is set to one, then the Ns field88and the Nr field90are present. The S bit68must be set to one for control messages48. If the Offset (“O”) bit70is set to one, then the Offset Size Field92is present. The Offset bit70must be set to zero for control messages48. If the Priority (“P”) bit71is set to one, then the data message46should receive preferential treatment in its local queuing and transmission. This feature is used only with data messages46. The P bit71must be set to zero for all control message48. The Version (“Ver”) field73indicates the version of the L2TP message header62.

The Length field82indicates the total length of the message60in octets. The Length field is optional for data messages46but not for control messages48.

The Tunnel I.D. field84indicates the identifier for the control connection for the establishment of the service tunnel. The Session I.D. field86indicates the identifier for a session within a service tunnel.

The Ns field88indicates the sequence number for a data message46or a control message48. The Ns field88is optional for data messages46, but not for control messages48.

The Nr field90indicates the sequence number expected in the next control message48to be received. The Nr field90is optional for data messages46, but not for control messages48.

The Offset Size field92, specifies the number of octets past the L2TP header62at which the payload data96is expected to start. The Offset Size field92is optional. Actual data within the Offset Padding field94is undefined. The Offset Padding field94is optional. If the Offset Padding field94is present, the L2TP header62ends after the last octet of the Offset Padding94.

For a field of header62that is indicated as optional for some or all messages. The space for that field does not exist in the message if the field is masked as not present.

FIG. 5illustrates the procedures120associated with the establishment of a service tunnel, the use of a service tunnel, and the tearing down of the service tunnel. At process block122, a control connection is used to establish the service tunnel, such as service tunnel30. Moving to process block124, an individual session is established within the service tunnel30. The service tunnel30supports multiple sessions.

At process block126, data is transported over the service tunnel30. The data comprises data messages46that encapsulate encapsulation services packets50and private IP packets52.

At process block128, a change is made with respect to the service tunnel session. Process flow then moves to process block130. At process block130, data messages46that encapsulate encapsulation services packets50and private IP packets52are transported during the changed session of the service tunnel30.

Process flow then moves to process block132, at which point the session is released. At process block132, the service tunnel still exists, but the session within the service ends.

Moving to process block134, the tunnel is then torn down.

FIG. 6illustrates the establishment of service tunnel30between virtual router21and virtual router22. Establishing service tunnel30comprises two main steps. The first step is the establishment of the control connection142for the service tunnel30. The control connection142is established between virtual router21and virtual router22. The second main step is the establishment of the session144as triggered by a request from one the CP routers, such as CP router14. The service tunnel30and the corresponding control connection142must be established before any transport of data over the session144is initiated.

Multiple service tunnel sessions may exist across a single service tunnel. For example, as shown inFIG. 6, service tunnel30includes both session144and session146. Session144is between end users at CP routers14and15. Session146is between CP routers17and19, which are part of a different enterprise than CP router14and15.

Furthermore, multiple service tunnels may exist between the same virtual routers. For example, there can exist multiple service tunnels between virtual router21and virtual router22, instead of just service tunnel30.

Control messages48(seeFIG. 2) are used in the establishment maintenance, and tearing down of service tunnels, such as service tunnels30–32. To maximize extensibility while still permitting interoperability, a uniform method for encoding control Message Types and bodies is used throughout L2TP. This encoding is called Attribute Value pair (AVP). An Attribute Value pair is defined as the variable length concatenation of unique attribute (represented by an integer) and a value containing the actual value identified by the attribute.

FIG. 7shows the Attribute Value pair format160. The format160is used for the encoding of each attributes value pair. The fields170,171and174together comprise a bit mask describing the general attributes of the AVP160. The reserved bits of field174are set to zero. The Mandatory (“M”) bit170controls the behavior required of an implementation that receives an AVP that it does not recognize. The Hidden (“H”) bit171identifies the hiding of data in the Attribute Value field182of the AVP160.

The Length field170encodes the number of octets (including the overall length and bit mask fields) contained in the AVP160. Field178is the Vendor ID field that identifies the particular L2TP extension.

The Attribute Type field180is a two octet value with a unique interpretation across all AVPs defined under a given Vendor ID178.

The Attribute Value field182is the actual value as indicated by the Vendor ID178and the Attribute Type180. The Attribute Value field182follows immediately after the Attribute Type field180and thus runs for the remaining octets indicated in the Length field176(i.e., the Length field176minus six octets of header). The minimum length of an AVP160is six octets. If the length of the AVP160is six octets, then the Attribute Value field182is absent.

Control message AVPs are used to establish the control connection142shown inFIG. 6. The control connection142is the initial connection that must be achieved between the virtual router21and the virtual router22before sessions, such as sessions144and146, may be brought up. Establishment of the control connection142includes securing the identity of the peer, as well as identifying the peers L2TP version, framing, and bearer capabilities etc. Establishment of the control connection142is also indicated by process block122inFIG. 5.

A three message exchange is used to setup the control connection142ofFIG. 6. The following is a typical message exchange. The virtual router21sends the Start Control Connection Request (“SCCRQ”) control message. The virtual router22responds with a Start Control Connection Reply (“SCCRP”) control message. The virtual router21then sends a Start Control Connection Connected (“SCCCN”) control message.

The virtual router22then responds with a Zero Length Body (“ZLB”) Acknowledgement message. A zero length body message is a control packet with only an L2TP header62. ZLB messages are used for explicitly acknowledging packets on the reliable control channel44. The ZLB Acknowledgement message is sent if there are no further messages waiting in queue for that peer.

The Start Control Connection Request control message is thus used to initialize service tunnel30. The following AVPs must be present in the Start Control Connection Request Control message: (1) Message Type AVP, (2) Service Type AVP200(described below), (3) Protocol Version, (4) Host Name, (5) Framing Capabilities, and (6) Assigned Tunnel ID.

FIG. 8illustrates the format of Service Type AVP200that is used for indicating which payload types are supported on sessions of the service tunnel30. In other words, Service Type AVP200indicates what types of payloads can be carried by payload96of data message46.

For Service Type AVP200, the length of the AVP is indicated in Length field176A. The Vendor ID field178ahas an ID number of 4741. Alternatively, the vendor ID field178acan contain the number zero and an attribute value chosen. The Attribute Type field180acontains the 16 bit quantity “1.”

The Attribute Value field182aindicates one of the service types. The service types can be the types of payloads that can be carried by data messages46. The types of payloads that can be specified include private IP packets52, encapsulation service packets50, PPP frames, ATM cells, frame relay frames, and TDM data, for example. The enterprise using the service tunnel30enters into a service contract with a service provider that specifies the particular payload types supported for that enterprise by the service tunnel30. For example, for one embodiment, service type zero could specify private IP packets52and service type A could specify PPP. Service type B could specify ATM cells. The service type specified in Attribute Value field182acan also indicate the type of connectivity services, reachability services, forwarding services, premium services (such as class of service and quality of service), addressing services, and peering services supported by service tunnel30for the particular subscriber or enterprise. The service type specified in Attribute Value field182acan also be of various (arbitrary) lengths. Moreover, depending upon the terms of the service contract entered into by the enterprise, more than one service type at a time can be specified in Attribute Value field182a. Thus, the service tunnel can handle more than one service type at a time.

The Service Type AVP200is an indication by an L2TP peer, such as virtual router21, that resources adequate for the service type identified by the Service Type AVP200are required. In the event that the L2TP peer, such as virtual router22, does not accept the requested service type, then a StopCCN message is returned to the orginator. The StopCCN message should include the Service Type AVP200as provided in the message that caused the StopCCN

The Service Type AVP200may be hidden (i.e., the H bit171amay be zero or one). The Length (before hiding) of the Service Type AVP200is six octets plus the length of the Service Type string of field182a.

The service tunnels30–32provide the mechanisms for protocol data units (“PDUs”) other than PPP to be tunneled via L2TP. In order to facilitate this in a backwards compatible manner, the M bit170ashould not be set on the Service Type AVP200unless the PPP tunneling protocol specified in document RFC 2261 is not supported. Thus, if RFC 2261 PPP tunneling is not supported by a particular implementation, the M bit170ashould be set to a logic one value on the Service Type AVP200in order to ensure that an implementation unaware of the Service Types other than PPP and/or requiring a Service Type PPP tunneling would disallow establishment of the L2TP tunnel.

Returning to the discussion of control messages used to establish the Control Connection142ofFIG. 6, the Start Control Connection Reply (“SCCRP”) control message is sent in reply to a received SCCRQ message. The following AVPs must be present in the SCCRP: (1) Message Type, (2) Service Type AVP200, (3) Protocol Version, (4) Framing Capabilities, (5) Host Name, and (6) Assigned Tunnel ID.

The Start Control Connection Connected (SCCN) control message is sent in reply to the SCCRP. The SCCCN control message completes the tunnel establishment process. The SCCN control message must include a Message Type AVP.

After the control connection142is established, the virtual routers21and22can optionally send messages to authenticate the formation of the service tunnel30shown inFIG. 6.

After a successful control connection142establishment, individual sessions may be created, which is indicated by process block124ofFIG. 5. Each session, such as session144shown inFIG. 6, corresponds to a single stream of data messages46between virtual router21and virtual router22. If private IP packets50are specified as the Service Type, then the data messages46would carry private IP packets52and encapsulation services packets50during the sessions. Unlike control connection142establishment, session establishment is directional with respect to the virtual router21and virtual router22. The virtual router21requests the virtual router22to accept a session for private IP packets52from CP router14. The virtual router22requests the virtual router21to accept a session for private IP packets52from CP router15.

A three message exchange is employed to setup a session involving private IP packets52incoming from GP router14. The following is a typical sequence of events. The virtual router21detects that CP router14wishes to send an incoming stream of private IP packets52. Virtual router21sends an Incoming Call Request (“ICRQ”) control message to virtual router22. Virtual router22responds by sending to virtual router21an Incoming Call Reply (“ICRP”) control message. The virtual router21responds by sending an Incoming Call Connected (“ICCN”) control message to virtual router22. A Zero Length Body Acknowledge message is sent from virtual router22to virtual router21if there are no further messages waiting in the queue for that peer.

For establishing a session involving the outgoing transport of private IP packets52from CP router15to CP router14over session144, a three message exchange is employed to setup the session. The following is a typical sequence of events. The virtual router22sends an Outgoing Call Request (“OCRO”) control message to virtual router21. Virtual router21then replies with an Outgoing Call Reply (“OCRP”) control message that virtual router21sends to virtual router22.

Once the private IP packets52are able to be transported and a connection through session144has been obtained, then the virtual router21sends an Outgoing Call Connected (“OCCN”) control message to virtual router22. Virtual router22then sends a Zero Length Body Acknowledgement message to virtual router21if there are no further messages waiting in queue for that peer.

The Incoming Call Request message is used to indicate that session144is to be established between virtual router21and virtual router22for the incoming private IP packets52and provides the virtual router22with parameter information for the session144. The virtual router21may defer establishing the session144until virtual router21has received an Incoming Call Reply control message from virtual router22indicating that the session should be established. This mechanism allows the virtual router22to obtain sufficient information about the incoming IP packets52before determining whether the session144should be established or not.

The following AVPs must be present in the Incoming Call Request message: (1) Message Type, (2) Sub-Address AVP220(described below), (3) Assigned Session ID, and (4) Call Serial Number.

The format of the Sub-Address AVP220is shown inFIG. 9. The Service Type AVP220encodes additional connection identifier information for the incoming or outgoing sending of data messages46. The Sub-Address AVP220must be located immediately following the Message Type AVP, unless it is hidden, in which case the Random Vector AVP will precede it.

The M bit170bfor the Sub-Address AVP220should be set to one. The Sub-Address AVP220may be hidden, so the H bit171bmay be a zero or a one. The Length (before hiding) of the Sub-Address AVP220is six octets plus the length of the Sub-Address in field182b,and the total length is placed in Length field176b.

For the Service Type AVP220, the Vendor ID field178bcontains the number 4741. For an alternative embodiment, the Vendor ID 1786 is zero and an attribute value is chosen. The Attribute Type field180bcontains the 16-bit quantity23.

The Attribute Value field182bof the Sub-Address AVP220contains sub-addresses of various (arbitrary) lengths. The sub-addresses stored in Attribute Value field182bcomprise an opaque sequence of octets transmitted transparently by the network11. The service tunnel30endpoints, such as virtual routers21and22, must understand the meaning of the values stored in Attribute Value field182bfor encapsulation services in this Sub-Address AVP. The sub-addresses stored in Attribute Value field182bcan include the calling party sub-address and the called party sub-address.

If virtual router21or virtual router22requires the use of the Sub-Address AVP220for every session and that router receives a Service Type AVP200without the M bit170aset to zero, then the service tunnel30must be torn down.

Returning toFIG. 6, the Incoming Call Reply control message is used to indicate that the Incoming Call Request control message was successful and for the virtual router21to communicate with the CP router14that the virtual router21is ready to accept private IP packets50if the virtual router21has not already done so. The Incoming Call Reply control message also allows the virtual router22to indicate the necessary parameters for the session144. The following AVPs must be present in the Incoming Call Reply control message: (1) Message Type and (2) Assigned Session ID.

The Incoming Call Connected control message is used to indicate that the Incoming Call Reply control message was accepted, that the virtual router21has established communication with the CP router14, and that the session144should move to the established state. It also provides additional information to the virtual router22about parameters used for the communication between virtual router21and CP router14. The following AVPs must be present in the Incoming Call Connected control message: (1) Message Type, (2) Transmission Connect Speed, and (3) Framing Type.

The Outgoing Call Request control message is used to indicate that a session144is to be established between the virtual routers21and22and provides the virtual router21with parameter information for both the session144and for the private IP packets52that are to be sent during the session.

The virtual router22must have received a Bearer Capabilities AVP during service tunnel establishment from the virtual router21in order to request the sending of private IP packets52to the virtual router21.

The Outgoing Call Reply control message is used to indicate that the virtual router21is able to attempt the outbound sending of private IP packets52and returns certain parameters regarding the attempt to send private IP packets52. The following AVPs must be present in the Outgoing Call Reply control message: (1) Message Type and (2) Assigned Session ID.

The Outgoing Call Connected control message is used to indicate that the result of a requested sending of private IP packets52was successful. The Outgoing Call Connected control message also provides information to the virtual router22about the particular parameters obtained after the sending of the private IP packets52was established. The following AVPs must be present in the Outgoing Call Connected control message: (1) Message Type, (2) Transmission Connect Speed, and (3) Framing Type.

Once the session144has been established, then the encapsulation services packets50and private IP packets52are transported over the service tunnel30, which is indicated by process block126inFIG. 5. With reference toFIGS. 3 and 6, the private IP packets52are received by virtual router21from CP router14. Virtual router21places the private IP packets52into the payload portions of encapsulation services packets50. Virtual router21also places the encapsulation services packets50(that encapsulate private IP packets52) into the payload portions96of service tunnel L2TP packets60to form data messages46. The virtual router21then forwards the data messages46(with their encapsulated private IP packets52and encapsulated services packets50) over session144and service tunnel30. The virtual router22receives the data messages46and extracts the encapsulated services packets50and private IP packets52. The virtual router22processes the encapsulated services packets50and private IP packets52as if they were received on a private IP packet network. The private IP packets52are then forwarded by virtual router22to CP router15.

The sender of a message associated with a particular session and service tunnel places the Session ID and Tunnel ID (specified by its peer) in the respective Session ID field86and Tunnel ID field84of the L2TP headers62of data messages46for all data messages46. In this manner, private IP packets52are multiplexed and demultiplexed over a single service tunnel between a given pair of virtual routers, such as virtual router21and virtual router22. Multiple service tunnels may exist between a given pair of virtual routers. In addition, multiple sessions may exist within a service tunnel.

FIG. 10illustrates encapsulation services (“ES”) packet50in more detail. Encapsulation services packet50includes an encapsulation services header256and a payload250. The encapsulation services header256is also referred to as the services tunnel header256or the in-band header256.

A private IP packet52shown inFIGS. 3 and 11is placed by virtual router21in the payload portion250of encapsulation services packet50shown inFIG. 3 and 10. The encapsulation services packet50is in turn placed by virtual router21in the payload portion96of L2TP packet60to form data message46. Thus, data message46encapsulates encapsulation services packet50, which in turn encapsulates private IP packet52.

The encapsulation services header of256of ES packet50shown inFIG. 10includes a Version Number field234. The Version Number of the private IP packet52(that is encapsulated as payload250) is inserted in field234in order to ensure forward compatibility.

The field236of ES header256indicates the type of compression used by the private IP packet52stored in payload250. Both sides of service tunnel30can negotiate for a compression scheme. Thus, virtual router21and virtual router22can negotiate for the compression scheme to be used for private IP packet52stored in payload250. Once a compression scheme has been negotiated and agreed to, then virtual router21can compress the private IP packets52according to that scheme. The field236would indicate the type of compression used for the private IP packets52. The virtual router22at the egress side would then decompress the private IP packets52using the compression field236for guidance as how to decompress the private IP packets52.

The field238of encapsulation services header256indicates whether the private IP packet52stored in payload250is encrypted. Both sides of service tunnel30negotiate for an encryption scheme when a session, such as session144, is established. Thus CP router14and CP router15negotiate for an encryption scheme for service tunnel30. Once the CP routers14and15have agreed upon encryption and the type of encryption, then the virtual router21at the egress side of the service tunnel30will encrypt the private IP packet52in payload250according to the encryption scheme.

Field246of ES header256contains an Encryption Index. The Encryption Index246points to which encryption key is used. If the private IP packets52in payload250are encrypted, the virtual router22at the egress side uses the key pointed to by the encryption index246to de-encrypt the private IP packet52in payload250.

The field240of the encapulation services header256indicates the payload type stored in payload250. The payload type that is indicated by the value stored in field240can either be a control payload or a data payload. Control payloads stored in payload250are used for session negotiation and management with respect to the service tunnel30. The data payload stored in payload250is private IP packet52, which in turn stores customer data being transported over service tunnel30.

A checksum value is stored in field244of encapsulation services header256for the purposes of error detection and correction with respect to ES packet50, including payload250. A checksum is a parameter used to detect errors. Checksums are calculated using a predetermined generator polynomial assigned to the specific checksum field244. The checksum244is included in header256to help to ensure that the header256will be detected once the ES packet50is transported.

Field248of encapsulation services header256stores a sequence number with respect to the ES packet50. The sequence number stored in field248indicates where this particular ES packet50fits within the sequence of ES packets over service tunnel30. The use of sequence numbers in field248for ES packets50is optional. The sequence number stored in field248can be used for security purposes to keep hackers from replaying ES packets50. Therefore, the sequence number in field248is typically used in conjunction with encryption to increase security. In addition, a sequence number can be stored in field248for control payload types involving session negotiation and management.

Payloads stored in payload field250of private IP packet50will in turn typically have their own headers and payloads.FIG. 11shows private IP packet52that includes a header302and a payload360. The header302includes a private IP address304used for the transport of the private IP packet52. The private IP address304is also referred to as the inner IP address304. CP router14sending data messages46over service tunnel30would encapsulate private IP packet52in ES packet50, which in turn would be encapsulated in data message46. The private IP packet52would include an inner IP address304that CP router14wants to send to CP router15for CP router15's use.

The following example of how inner IP addresses (such as those stored at private IP address field304) are handled by the service tunnels is made with reference toFIG. 2. Virtual routers21,22, and23advertise which virtual private networks they handle and which inner IP addresses on those virtual private networks they handle. For example, virtual routers21,22, and23would advertise to each other that they manage virtual private network A and the inner IP addresses associated with the virtual private network A. If CP router14wishes to send a data packet to inner IP address168, CP router14sends the private IP packet52to virtual router21. Virtual router21realizes that this inner IP address168is associated with virtual private network A and then decides how virtual router21can reach this inner IP address168and virtual private network A. Virtual router21has received advertisements from virtual routers22and virtual routers23regarding the inner IP addresses they can reach. Therefore, virtual router21has in a lookup table (i.e., forwarding table) the information regarding the inner IP addresses and how to reach them. Virtual router21uses the forwarding table to determine that inner IP address168can be reached through virtual router23. Virtual router21then looks up to see which service tunnel can be used to get to virtual router23. Virtual router21also decides which session needs to be used within the service tunnel to get to virtual router23to reach the inner IP address of168. For example, the virtual router21determines that service tunnel32should be used to get to virtual router23and that Session ID446within service tunnel32should be used to get to virtual router23for inner IP address168.

Virtual router21then encapsulates the private data IP packets52of CP router14within ES packets50, which CP router21in turn encapsulates within the service tunnel L2TP packets60, which become the data messages46. The virtual router21sets the Tunnel ID84within L2TP header62to indicate service tunnel32. The virtual router21also inserts Session ID446of L2TP header62. Virtual router21then sends the data messages46over service tunnel32and session446to virtual router23. The payload250of each ES packet50is compressed or encrypted according to the encapsulation services header256.

The virtual router23receives the service tunnel data messages46with their data stored in payload portion96. Virtual router23looks at the Tunnel ID in field84, which is service tunnel32, and the Session ID in the field86, which is Session ID446, and maps the payload96onto virtual private network A. The virtual router23then de-encapsulates (i.e., extracts) the payload96into private IP data packets52having an inner IP address168and sends those private IP data packets52to CP router16. CP router16uses the inner IP address168to look up in its router table where to send the data packets52. The customer or subscriber at inner IP address168then receives the data packets52from CP router16.

Returning toFIG. 5, once a session has been established, process block124, the session (such as session144) can be changed at process block128. An example of a session change would be changing a session from sending voice information to fax information. If service tunnel30has been established and session144within service tunnel30has been established, as shown inFIG. 3, CP router14may decide to stop sending voice information over session144and instead wish to send fax information over session144. The end user at CP router14would notify the service provider responsible for maintaining service tunnel30of his or her wish to change from a voice session to a fax session. This could be done either manually through a telephone call or by sending an appropriate control message. The service provider would send a message to virtual router21to change the type of session from a voice session to a fax session. Virtual router21would then send the appropriate control message to virtual control router22to ensure that the session is changed from a voice session to a fax session. The change in the character of the session144would be done without tearing down the session144or tearing down the service tunnel30.

Another example of a change of a session within service tunnel30, such as session144, would be a change in addressing. For example, one of the inner IP addresses within a virtual private network might be withdrawn. An employee of an enterprise may leave and his or her inner IP address may be deleted. The service provider would accordingly send an appropriate protocol message to virtual router21to change the routing tables. Virtual router21would in turn send appropriate messages to the other virtual routers22and23to have their routing tables changed with respect to the inner IP addresses available on the particular virtual private network. Again, this would be done without tearing down the session or tearing down the tunnel. Instead, there would simply be a change with respect to the session144established.

Changes done with respect to sessions without tearing down the session or tearing down the tunnel are conducted through in-band signaling because they use encapsulated messages or relate to encapsulated messages. In-band signaling can be used to handle service provisioning. Service provisioning has two parts. The first part is the order entry. In other words, an end user or subscriber wishes to change the type of service and submits an order entry to the service provider. The second part of provisioning is the change of the Service Type. In other words, the type of session is changed.

Process block132shown inFIG. 5refers to releasing a session, such as session144, which is also referred to as session teardown. Session teardown may be initiated by either the virtual router21or virtual router22and is accomplished by sending a Call Disconnect Notify (“CDN”) message. The following is an example of a typical control message exchange between virtual21and virtual router22. Virtual router21sends a Call Disconnect Notify control message to virtual router22. Virtual router22responds and sends a Zero Length Body Acknowledge message to virtual router21.

The purpose of the Call Disconnect Notify message is to inform the peer of the disconnection and the reason why the disconnection occurred. The peer must clean up any resources, and does not send back any indication of success or failure of such cleanup. The follow AVPs must be present in the Call Disconnect Notify call message: (1) Message Type, (2) Result Code, and (3) Assigned Session ID.

After the last session within service tunnel30is cleared, the control connection142may be torn down as well and typically is. Control connection teardown is indicated by process block134inFIG. 5. Process block134refers to tearing down the tunnel. Tearing down the control connection142tears down the service tunnel30.

Control connection142teardown may be initiated by either virtual router21or virtual router22and is accomplished by sending a single Stop Control Connection Notification (“StopCCN”) control message. The receiver of a Stop Control Connection Notification control message must send a Zero Length Body Acknowledgement message to acknowledge receipt of the message and maintain enough control connections to properly accept Stop Control Connection Notification retransmissions over at least a full retransmission cycle in case the Zero Length Body Acknowledgement message is lost.

For one embodiment of the invention, the entire service tunnel may be shut down and all sessions on the service tunnel can be shut down by sending the Stop Control Connection Notification control message. Thus, for that embodiment, it is not necessary to teardown each session (such as session144) individually when tearing down the whole service tunnel.

For one embodiment of the present invention, virtual routers21through23each contain network process servers containing application specific integrated circuit processors.

For one embodiment of the invention, service tunnels30through32allow the performance monitoring of packet transmissions. For example, the number of packets received and transmitted at each end of the service tunnels can be monitored in order to see how many packets have been lost within the network. For another embodiment, the roundtrip time of packets over the service tunnel can be monitored using timestamps. Also, the roundtrip time can be measured by echoing packets back and forth across a service tunnel. A time stamp can be used to stamp the time that a packet enters the service tunnel and a time stamp can be used when the packet is received back over the service tunnel. The average round trip time can then be calculated. Maximum and minimum round trip times give an indication of jitter. This information is useful for administration of the network so that performance of the network can be tuned.

For an alternative embodiment of the invention, redundant service tunnels can be established in order to have backup tunnels in case of service disruptions.

For an alternative embodiment, call forwarding can be implemented using a two-segment tunnel. For that alternative embodiment, tunnels can be segmented and packets can be forwarded over new segments of the tunnels. This alternative embodiment would be useful for cell phones, PDAs, wireless, and mobile IP devices. Methods can be implemented to predict where tunnel segments will be needed as a cell phone moves across geographical areas.

For another alternative embodiment of the present invention, tunnel relays are created to relay information from one tunnel to another.

For another alternative embodiment of the invention, the service tunnels30,31, and32can transport virtual private networks as sessions, wherein the virtual private networks transport information according to MPLS rather than according to pure IP. This contrasts with having network12being an MPLS network, which is another alternative embodiment of the present invention.