Electrical computers and digital processing systems: multicomput – Computer-to-computer session/connection establishing
Reexamination Certificate
1999-04-02
2003-11-25
Thompson, Marc D. (Department: 2142)
Electrical computers and digital processing systems: multicomput
Computer-to-computer session/connection establishing
C709S228000
Reexamination Certificate
active
06654808
ABSTRACT:
FIELD OF THE INVENTION
This invention relates generally to communications and, more particularly, to packet communications systems.
BACKGROUND OF THE INVENTION
In the past, all data traffic using the Internet was treated equally and transported using a “best effort” mechanism. However, over time, the need to support real-time applications over the Internet (e.g., audio/video conferencing tools, gaming applications, etc.) necessitated some form of differentiated services offering. As such, those in the art are defining new protocols for providing quality of service (QoS) to Internet users. (QoS is also referred to as Type of Service (ToS).) For example, the article “An Architecture for Differentiated Services,” RFC2475, December 1998 by S. Blake, et al., defines six bits within the TOS byte in the Internet Protocol (IP) header for conveying a code point which represents a certain QoS. Similarly, the article “An Expedited Forwarding PHB”, draft-ietf-diffserv-phb-ef-01.txt, November 1998, by V. Jacobson, et al., describes one specific code point that allows users to subscribe to different configured rates just like the Constant Bit Rate (CBR) service in ATM. The article “Assured Forwarding PHB Group”, draft-ietf-diffserv-af-03.txt, December 1998, by J. Heinanen, et al. describes other types of services that are similar to Real Time/Non Real-Time Variable Bit Rate (VBR) services in ATM. And, the article “PPP in a real-time oriented HDLC-like framing,” by C. Bormann, WETF draft August 1998, proposes a suspend/resume-oriented solution for providing integrated services over low-bitrate links. (PPP stands for Point-to-Point Protocol.) This proposal builds from the PPP multilink fragmentation protocol (e.g., see K. Slower etc “
The PPP Multilink Protocol
(
MP
),” RFC1990, August 1996) and its multi-class extension (e.g., see C. Bormann, “
The Multi-class Extension to Multilink PPP
,” IETF draft August 1998).
One use of the Internet as a communications vehicle is as an enhanced data back-bone for coupling together different sites to provide what is referred to as a “virtual private network” (VPN). One application of a VPN is in a corporate environment such that employees, e.g., at home, can remotely access, via the Internet, corporate data networks. A VPN provides security, and authentication, for a remote user to join a closed user group notwithstanding the use of public facilities. In effect, the use of a VPN provides a WAN-like vehicle to the corporation and its employees. (Although the corporate network could also provide direct remote access, e.g., a user dials directly into the corporate network, there are economic advantages to the use of a VPN.)
To provide a VPN, tunneling protocols are used such as the “Point-to-Point Tunneling protocol” (PPTP) and the “Layer 2 Forwarding” (L2F) protocol. Generally speaking, a tunnel protocol enables the creation of a private data stream via a public network by placing one packet inside of another. In the context of a VPN, an IP packet is placed inside another IP packet (IP-in-IP). In an attempt to develop an industry standard, the Internet Engineering Task Force (IETF) is developing the “Layer 2 Tunneling Protocol” (L2TP), which is a hybrid of the PPTP and L2F protocols (e.g., see K. Hamzeh, T. Kolar, M. Littlewood, G. Singh Pall, J.Taarud, A. J. Valencia, W. Verthein;
Layer Two Tunneling Protocol “L
2
TP
”; Internet draft, March, 1998).
For a remote user, a typical form of access to a VPN is via a “plain-old-telephone service” (POTS) connection to an “Internet service provider” (ISP) that provides the VPN service. For example, a user incorporates an analog modem into a personal computer, or equivalent, and has a customer account with a particular ISP, referred to herein as the “home” ISP. (It is also assumed that the user's personal computer is properly configured to support one of the above-mentioned tunneling protocols.) The user accesses the VPN by simply making a data call to the home ISP, e.g., dialing a telephone number associated with the “home” ISP and then “logging in” to the VPN.
As noted above, in L2TP, a tunnel is established between two VPN service providers for carrying a number of calls. Unfortunately, the above-mentioned L2TP protocol does not address “Quality of Service” (QoS) issues (also know as Differential Services). As such, some users may be reluctant to adopt L2TP without QoS assurances such as a guaranteed minimum bandwidth for a call. Consequently, those in the art have suggested modifying L2TP such that after a tunnel is established, a per-call QoS can be negotiated using only a single code point value (e.g., see “Layer Two Tunneling Protocol ‘L2TP’ IP Differential Services Extension,” July 1998, draft-ietf-pppext-12tp-ds-02.txt [@http://www.ietf.org)].
SUMMARY OF THE INVENTION
Unfortunately, providing a per-call QoS using a single code point value is not a complete solution to the problem in an L2TP-based system. In particular, I have realized that the above-mentioned
PPP Multilink Protocol
(
MP
) and, its multi-class extension should also be supported in an L2TP environment. Therefore, and in accordance with the invention, the control signaling in L2TP is modified to support multiple classes of service within a call.
In an embodiment of the invention, new Attribute Value Pairs (AVP)s are defined for use in the L2TP control messages for setting up a call (as defined in L2TP, AVPs are used to further specify control signaling). In particular, an L2TP Incoming-Call-Request (ICRQ) or Outgoing-Call-Request (OCRQ) message includes a QoS Request AVP, which includes a field for defining the number of classes of service, or QoS, within the call. One QoS for each PPP multi-class extension.
In another embodiment of the invention, a new QoS_Request extension and a new QoS_Reply extension are defined for use in Mobile IP networks.
REFERENCES:
patent: 5674003 (1997-10-01), Andersen et al.
patent: 5917822 (1999-06-01), Lyles et al.
patent: 5940390 (1999-08-01), Berl et al.
patent: 6094437 (2000-07-01), Loehndorf, Jr. et al.
patent: 6137791 (2000-10-01), Frid et al.
patent: 6154778 (2000-11-01), Koistinen et al.
patent: 6157955 (2000-12-01), Narad et al.
patent: 6167028 (2000-12-01), Harris
patent: 6223028 (2001-04-01), Chang et al.
patent: 6223222 (2001-04-01), Fijolek et al.
patent: 6339595 (2002-01-01), Rekhter et al.
patent: WO 9845966 (1994-08-01), None
patent: WO 9507578 (1997-08-01), None
Jain, Mobile Internet Access and QOS Guarantees Using IP and RSVP with Location Registers, ICC '98.*
K. Hamzeh, T. Kolar, M. Littlewood, G. Singh Pall, J. Taarud, A. J. Valencia, W. Verthein, W. M. Towsley, B. Palter, A. Rubens, “Layer Two Tunneling Protocol (L2TP)”, Internet Draft, Oct. 1997.
V. Jacobson, et al., “An Expedited Forwarding PHB”, draft-ietf-diffserv-phb-ef-01.txt, Nov. 1998.
S. Blake, et al., “An Architecture for Differentiated Services”, RFC2475, Dec. 1998.
J. Heinanen, et al., “Assured Forwarding PHB Group”, draft-ietf-diffserv-af-03.txt, Dec. 1998.
S. Shenker, et al., “Specification of Guaranteed Quality of Service”, rfc2212.txt, Sep. 1997.
P. Calhoun, “Layer Two Tunneling Protocol ‘L2TP’ IP Differential Services Extension”, Internet Draft, Jul. 1998 draft-ietf-pppext-12tp-ds-02.txt @ http://www.ietf.org.
C. Bormann, “The Multi-class Extension to Multilink PPP,” IETF draft Aug. 1998.
C. Bormann, “PPP in a real-time oriented HDLC-like framing,” IETF draft, Aug. 1998.
K. Slower et al., “The PPP Multilink Protocol (MP)”, RFC1990, Aug. 1996.
C. Perkins et al., “IP Mobility support,” RFC2002, Oct. 1996.
S. Blake et al., “An architecture for differentiated services,” RFC2475 Dec. 1998.
C. Perkins, “IP encapsulationin IP”, RFC2003, Oct. 1996.
Lucent Technologies - Inc.
Thompson Marc D.
LandOfFree
Proving quality of service in layer two tunneling protocol... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Proving quality of service in layer two tunneling protocol..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Proving quality of service in layer two tunneling protocol... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3183939