CA2300758C - Providing quality of service in layer two tunneling protocol networks - Google Patents
Providing quality of service in layer two tunneling protocol networks Download PDFInfo
- Publication number
- CA2300758C CA2300758C CA002300758A CA2300758A CA2300758C CA 2300758 C CA2300758 C CA 2300758C CA 002300758 A CA002300758 A CA 002300758A CA 2300758 A CA2300758 A CA 2300758A CA 2300758 C CA2300758 C CA 2300758C
- Authority
- CA
- Canada
- Prior art keywords
- qos
- service
- call
- classes
- l2tp
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2854—Wide area networks, e.g. public data networks
- H04L12/2856—Access arrangements, e.g. Internet access
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2854—Wide area networks, e.g. public data networks
- H04L12/2856—Access arrangements, e.g. Internet access
- H04L12/2858—Access network architectures
- H04L12/2859—Point-to-point connection between the data network and the subscribers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2408—Traffic characterised by specific attributes, e.g. priority or QoS for supporting different services, e.g. a differentiated services [DiffServ] type of service
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/168—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP] specially adapted for link layer protocols, e.g. asynchronous transfer mode [ATM], synchronous optical network [SONET] or point-to-point protocol [PPP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
- H04W28/24—Negotiating SLA [Service Level Agreement]; Negotiating QoS [Quality of Service]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
Abstract
New Attribute Value Pairs (AVP)s are defined for use in the L2TP control messages for setting up a call. 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 within the call. In another embodiment, a new QoS_Request extension and a new QoS_Reply extension are defined for use in Mobile IP networks.
Description
Providing Quality of Service in Layer Two Tunneling Protocol Networks 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 Ol.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-of 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, IETF 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
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 Ol.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-of 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, IETF 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)," RFC 1990, 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 erect, 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 "L2TP' ; 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 protocol does not address "Quality of Service" (QoS) issues (also known 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-l2tp-ds-02.txt @
http://www. ietf. orgy.
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.
Brief Description of the Drawing FIG. 1 shows portions of L2TP packets with encapsulated MP packets as known in the prior art;
FIG. 2 shows a communications system in accordance with the principles of the invention;
FIG. 3 shows a llow chart of an illustrative method for use in the communications system of FIG. 2;
FIG. 4 illustrates a control message transaction for negotiating a call in accordance - with the principles of the invention;
' FIGS. 5 - 6 illustrate new Attribute Value Pair L2TP messages for use in accordance with the principles of the invention;
FIG. 7 illustrates another control message transaction for negotiating a call in accordance with the principles of the invention;
FIG. 8 shows portions of L2TP packets with encapsulated MP packets in accordance with the principles of the invention;
FIG. 9 shows an illustrative high-level block diagram of a packet server;
FIG. 10 shows another communications system in accordance with the principles of the invention;
FIGS. 11 - 12 illustrate other QoS-type messages for use in accordance with the principles of the invention;
FIG. 13 shows portions of Mobile IP packets conveying Registration and Reply messages in accordance with the principles of the invention; and FIG. 14 shows a portion of a modified multilink header.
Detailed Description Before describing the inventive concept, an illustration of prior art MP
transmission is described via FIG. 1, which shows portions of L2TP packets with encapsulated MP packets. (It should be noted that this figure, and subsequent similar figures, show summaries of the relevant information conveyed in the packets and do not represent all of the fields in the packets.) L2TP packet 10 has a defined quality-of service field as represented by ToS 1 (the more common reference within IP is the Type-of Service field). This field is followed by an L2TP sequence number field, illustratively set to 1. The L2TP sequence number field is followed by a PPP header field and an MP class field, which illustratively indicates this packet as having class 1. As known in the art, L2TP control messages and different L2TP data sessions use different sequence number spaces, or sets of sequence numbers. In particular, L2TP currently requires a different sequence number space, or set of sequence numbers, for each transmitted PPP
packet of a particular class or link. This is illustrated by L2TP packets 11 and 12 which are part of session 1. L2TP packet 11, which conveys the next class 1 packet, uses the same sequence number set as L2TP packet 10 and the value for this field is simply the next number in the sequence (or in the sequence number set), i.e., 2. However, when a different class of PPP data is encountered, i.e., a different L2TP data session and hence a different sequence numbering space, or sequence number set, is used. This is illustrated by L2TP packet 12 of session 2, which conveys PPP data having an MP class 2 and using an entirely different sequence numbering, e.g., 31.
Turning now to FIG. 2, the latter shows an illustrative communications system in accordance with the principles of the invention. Other than the inventive concept, the elements are well-known and will not be described in detail. For example, personal computer (PC) 105 includes data communications equipment (not shown) for dial-up access through public-switched-network (PSTN) 110 to ISP A for establishing an Internet connection. Likewise, the solid lines between elements of communications system 100 are representative of well-known communications facilities between the respective endpoints, e.g., the connection between PC 105 and PSTN 110 is representative of a local loop 1 S connection, the connection between ISP A and Internet 130 is supported by asynchronous transfer mode (ATM) over a synchronous optical network (SONET), etc. Further, its assumed that the reader is familiar with the above-mentioned L2TP protocol, Expedited Forwarding Service, Assured Forwarding Service, and the PPP Multilink Protocol (MP) along with its multi-class extension (hereafter referred to as the MP
protocol).
At this point, the following definitions are assumed:
mL2TP - the L2TP protocol as defined in K. Hamzeh, T. Kolar, M.
Littlewood, G. Singh Pall, J.Taarud, A. J. Valencia, W. Verthein; Layer Two Tunneling Protocol "L2TP"; Internet draft, March, 1998; plus modiftcations as described herein;.
LAC - mL2TP Access Control, i.e., a Network Access Server (NAS) that supports mL2TP; and LNS - a Network Server (NS) that supports mL2TP;
(These definitions are used to simplify an illustrative description of the inventive concept. As such, and as those in the art will realize, the inventive concept is not so limited and can be applied to any tunneling protocol and associated processing equipment. ) - As can be observed from FIG. 2, communications system 100 comprises ISP A, as represented by ISP A Network. The latter comprises LAC 155 (also referred to as a "serving LAC"), which includes a point-of presence (POP) router (not shown) as known in the art, a local network 160, and a router 165. It is assumed that ISP A
provides a VPN service for remotely located employees to access an illustrative corporate network via LNS 135, which provides, among other functions, a routing and firewall capability.
(The corporate network is assumed to be, e.g., a collection of local area networks (not shown) suitably protected behind LNS 135.) The VPN service, e.g., for a user associated with PC 105, is represented by dotted lines 1 and 2, via the ISP A Network. At this point, the connectivity is a point-to-point MP session whose endpoints are the remote user's networking application on one end (as represented by PC 110) and the termination of this connectivity into LNS 13 S on the other. (It should be noted that accounting, if necessary, can be performed at the Serving LAC, as well as the LNS, i.e., each element may count packets, octets and connection start and stop times.) For the purposes of this description, it is assumed that a tunnel (for supporting the VPN service) has already been set up, or negotiated, between the serving LAC
and the LNS using either known L2TP techniques or the method described in the above-referenced U.S. Patent application of Chuah, entitled "Providing Quality of Service in Layer Two Tunneling Protocol Networks." Further, it is assumed that the user desires access to the VPN service and has been authenticated. (For example, for secure conduits, the IETF has defined two protocols for security - the Password Authentication Protocol (PAP) and the Challenge-Handshake Authentication Protocol (CHAP) (e.g., see IETF
Request for Comment (RFC) 1334, "PPP Authentication Protocols"). Obviously, if LAC
155 can not authenticate the user, the connection is not accepted. In the context of this invention, it is presumed that the connection between the user and the serving LAC
supports the MP protocol and is similarly authenticated.) For an individual session, or call, the LAC (or LNS) receives requests for setting up an incoming call from a user (or an outgoing call to a user). In accordance with the inventive concept, each individual session can request multiples QoS classes.
The LAC
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 erect, 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 "L2TP' ; 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 protocol does not address "Quality of Service" (QoS) issues (also known 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-l2tp-ds-02.txt @
http://www. ietf. orgy.
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.
Brief Description of the Drawing FIG. 1 shows portions of L2TP packets with encapsulated MP packets as known in the prior art;
FIG. 2 shows a communications system in accordance with the principles of the invention;
FIG. 3 shows a llow chart of an illustrative method for use in the communications system of FIG. 2;
FIG. 4 illustrates a control message transaction for negotiating a call in accordance - with the principles of the invention;
' FIGS. 5 - 6 illustrate new Attribute Value Pair L2TP messages for use in accordance with the principles of the invention;
FIG. 7 illustrates another control message transaction for negotiating a call in accordance with the principles of the invention;
FIG. 8 shows portions of L2TP packets with encapsulated MP packets in accordance with the principles of the invention;
FIG. 9 shows an illustrative high-level block diagram of a packet server;
FIG. 10 shows another communications system in accordance with the principles of the invention;
FIGS. 11 - 12 illustrate other QoS-type messages for use in accordance with the principles of the invention;
FIG. 13 shows portions of Mobile IP packets conveying Registration and Reply messages in accordance with the principles of the invention; and FIG. 14 shows a portion of a modified multilink header.
Detailed Description Before describing the inventive concept, an illustration of prior art MP
transmission is described via FIG. 1, which shows portions of L2TP packets with encapsulated MP packets. (It should be noted that this figure, and subsequent similar figures, show summaries of the relevant information conveyed in the packets and do not represent all of the fields in the packets.) L2TP packet 10 has a defined quality-of service field as represented by ToS 1 (the more common reference within IP is the Type-of Service field). This field is followed by an L2TP sequence number field, illustratively set to 1. The L2TP sequence number field is followed by a PPP header field and an MP class field, which illustratively indicates this packet as having class 1. As known in the art, L2TP control messages and different L2TP data sessions use different sequence number spaces, or sets of sequence numbers. In particular, L2TP currently requires a different sequence number space, or set of sequence numbers, for each transmitted PPP
packet of a particular class or link. This is illustrated by L2TP packets 11 and 12 which are part of session 1. L2TP packet 11, which conveys the next class 1 packet, uses the same sequence number set as L2TP packet 10 and the value for this field is simply the next number in the sequence (or in the sequence number set), i.e., 2. However, when a different class of PPP data is encountered, i.e., a different L2TP data session and hence a different sequence numbering space, or sequence number set, is used. This is illustrated by L2TP packet 12 of session 2, which conveys PPP data having an MP class 2 and using an entirely different sequence numbering, e.g., 31.
Turning now to FIG. 2, the latter shows an illustrative communications system in accordance with the principles of the invention. Other than the inventive concept, the elements are well-known and will not be described in detail. For example, personal computer (PC) 105 includes data communications equipment (not shown) for dial-up access through public-switched-network (PSTN) 110 to ISP A for establishing an Internet connection. Likewise, the solid lines between elements of communications system 100 are representative of well-known communications facilities between the respective endpoints, e.g., the connection between PC 105 and PSTN 110 is representative of a local loop 1 S connection, the connection between ISP A and Internet 130 is supported by asynchronous transfer mode (ATM) over a synchronous optical network (SONET), etc. Further, its assumed that the reader is familiar with the above-mentioned L2TP protocol, Expedited Forwarding Service, Assured Forwarding Service, and the PPP Multilink Protocol (MP) along with its multi-class extension (hereafter referred to as the MP
protocol).
At this point, the following definitions are assumed:
mL2TP - the L2TP protocol as defined in K. Hamzeh, T. Kolar, M.
Littlewood, G. Singh Pall, J.Taarud, A. J. Valencia, W. Verthein; Layer Two Tunneling Protocol "L2TP"; Internet draft, March, 1998; plus modiftcations as described herein;.
LAC - mL2TP Access Control, i.e., a Network Access Server (NAS) that supports mL2TP; and LNS - a Network Server (NS) that supports mL2TP;
(These definitions are used to simplify an illustrative description of the inventive concept. As such, and as those in the art will realize, the inventive concept is not so limited and can be applied to any tunneling protocol and associated processing equipment. ) - As can be observed from FIG. 2, communications system 100 comprises ISP A, as represented by ISP A Network. The latter comprises LAC 155 (also referred to as a "serving LAC"), which includes a point-of presence (POP) router (not shown) as known in the art, a local network 160, and a router 165. It is assumed that ISP A
provides a VPN service for remotely located employees to access an illustrative corporate network via LNS 135, which provides, among other functions, a routing and firewall capability.
(The corporate network is assumed to be, e.g., a collection of local area networks (not shown) suitably protected behind LNS 135.) The VPN service, e.g., for a user associated with PC 105, is represented by dotted lines 1 and 2, via the ISP A Network. At this point, the connectivity is a point-to-point MP session whose endpoints are the remote user's networking application on one end (as represented by PC 110) and the termination of this connectivity into LNS 13 S on the other. (It should be noted that accounting, if necessary, can be performed at the Serving LAC, as well as the LNS, i.e., each element may count packets, octets and connection start and stop times.) For the purposes of this description, it is assumed that a tunnel (for supporting the VPN service) has already been set up, or negotiated, between the serving LAC
and the LNS using either known L2TP techniques or the method described in the above-referenced U.S. Patent application of Chuah, entitled "Providing Quality of Service in Layer Two Tunneling Protocol Networks." Further, it is assumed that the user desires access to the VPN service and has been authenticated. (For example, for secure conduits, the IETF has defined two protocols for security - the Password Authentication Protocol (PAP) and the Challenge-Handshake Authentication Protocol (CHAP) (e.g., see IETF
Request for Comment (RFC) 1334, "PPP Authentication Protocols"). Obviously, if LAC
155 can not authenticate the user, the connection is not accepted. In the context of this invention, it is presumed that the connection between the user and the serving LAC
supports the MP protocol and is similarly authenticated.) For an individual session, or call, the LAC (or LNS) receives requests for setting up an incoming call from a user (or an outgoing call to a user). In accordance with the inventive concept, each individual session can request multiples QoS classes.
The LAC
(or LNS) determines the relevant trai~ic parameters and QoS (codepoints) (described - below) based on the user's a priori defined profile or as defined in the received MP
messages. (In the former case, the LAC (or LNS) communicates with a respective Authentication Authorization and Accounting (AAA) server, as known in the art, to obtain user profiles based on, e.g., user login name. However, for the remainder of this description, the inventive concept is described in the context of an incoming call to LAC
155 using MP.) In support of the above-described virtual dial up service, and in accordance with the inventive concept, a form of the L2TP (mL2TP) protocol is used. As in L2TP, there are two parallel components of mL2TP operating over a given tunnel: control messages between each LAC-LNS pair, and payload packets between the same LAC-LNS pair.
The latter are used to transport mL2TP encapsulated MP packets for user data sessions between the LAC-LNS pair. As in L2TP, the Nr (Next Received) and Ns (Next Sent) fields are always present in control messages and are optionally present in payload packets. The control messages and payload messages use different sequence number sets.
For the above-mentioned LAC-LNS pair scenario, there are no changes to the L2TP draft protocol definition as far as the maintenance and usage of (Nr, Ns) is concerned.
As noted above, before the call is established, mL2TP control messages are exchanged between the Serving LAC and the LNS. Therefore, new Attribute Value Pairs (AVP)s (described below) are defined for use in the L2TP control messages (hence becoming mL2TP control messages) for enabling two mL2TP peers to set up, or negotiate, a call having multiple classes of service. As such, it should be realized that -other than the additional QoS negotiation for establishing such a call - L2TP
tunnel set up procedures are unchanged.
Reference should now be made to FIG. 3, which shows an illustrative high-level flow chart of a method in accordance with the principles of the invention for negotiating multiple QoS within a single call. (It is presumed that LAC 155 and the other respective servers are suitably programmed to carry out the below-described methods using conventional programming techniques, which, as such, will not be described herein.) In step 305 of FIG. 3, the serving LAC receives one PPP LCP frame with a multilink header -$-from the user. Upon identification of the multilink header, the serving LAC
(e.g., LAC
' 155), examines the "# Susp Clses" field of the multilink header. In particular, the serving LAC checks the value of the "# of Susp Clses" field and the associated values of the ToS
values within the modified multilink header and creates an appropriate QoS
Request AVP
S for attachment to an ICRQ message (described below). (As known in the art, the "# Susp Clses" field is currently available in a multilink header. Therefore, and, in accordance with the inventive concept, a multilink header is modified as shown in FIG. 14 to convey additional QoS information (in FIG. 14, illustratively 3 ToS.) In step 315, the serving LAC transmits the ICRQ message with the QoS Request AVP. In accordance with the inventive concept, the QoS Request AVP specifies how many QoS classes are associated with this call and the types of QoS (described further below). The serving LAC, in step 320, receives a reply with a QoS Reply AVP in the received ICRP message. The serving LAC then responds with an Incoming-Call-Connected (ICCN) message in step 325.
A
corresponding illustrative control message transaction for performing the above-described negotiation is shown in FIG. 4 between two mL2TP peers (here represented by a LAC and an LNS).
Turning to FIG. 5, an illustrative format of a QoS Request AVP is shown. The first four bits of this AVP have a predefined bit pattern of "1100" (as defined L2TP), bit positions 4 and 5 are "don't cares," and bit positions 6 and 7 convey two new parameters, D, and L, where D is representative of a delay class bit, and L is representative of a Loss class. The D bit is used if the underlying tunnel supports delay classes only.
In other words, if the D bit is set in an ICRQ message, only the delay bits of the differentiated code point value are taken into consideration (described below). Similarly, the L
bit is used if the underlying tunnel supports loss classes only, i.e., if the L bit is set only the loss bits of the code point are taken into consideration.
Following the D and L bits is a eight bit length field, the value for which is the size of this AVP. After the length field, there is a two byte Vendor specific ID
(here illustratively shown as conveying the data representative of a Lucent identifier (Lucentid) and also denoting that this is a call message having multiple QoS).
(Alternatively, this could be replaced by a predefined mL2TP AVP code signifying that this is a call message having multiple QoS.) The Vendor specific ID is followed by a two byte L2TP
attribute type field, here set to 1. After the attribute field there is a "number of classes" field that specifies the number of QoS being requested. In this example, the number of classes field is equal to the number of different classes determined in step and 305 of FIG.
3.
Following the number of classes field, there are as many differentiated services code point values (QoS identifiers that are one byte in length) as are specified by the value of the number of classes field. (For the QoS Request AVP of FIG. 5, the value of the number of classes field is illustratively three.) Each QoS specifies a particular class of differentiated service for an associated PPP class extension. In addition, the first two bits of each QoS bytes are representative of a promotable bit, P, and a demotable bit, M. In other words, the P and M bits are used on a per-class basis. When the P and M
bits represent a zero value, the mL2TP peer is indicating that only the chosen differentiated code point value is to be used on IP packets within the session's data channel for that class. When the P bit is set, it means that the mL2TP peer can recommend a differentiated service code point value with a higher level of service if the requested one is not available for a class. When the M bit is set, it means that the mL2TP peer can recommend a differentiated service code point value with a lower level of service should the requested one not be available for a class. Following the multiple QoS fields, a "padding" field is used to fill the AVP message, if necessary.
The values of the differentiated service code point values are defined in a fashion similar to the definition of codepoints in the above-mentioned Assured Forwarding (AF) Service. In particular, the two mL2TP peers may set up classes A;~ with a call, where i represents a type of delay class and j represents a type of loss class. For the purposes of example only, i = l, 2, 3, 4; and j = 1, 2, 3. As such, there are 4 classes for a call each class supporting a different delay priority class, i.e., with differentiated service code points Aix, i = l, 2, 3, 4, as shown in the table, below.
Aix Differentiated Service Code Point Value Alx OO1XXX
A2x O 10~
A3x 011 A4x ~ 100 Delay Priority Classes The "X" represents a "don't care" condition, i.e., the value can be a binary zero or a binary one. Individual sessions with differentiated service code points Aij are mapped to a tunnel supporting differentiated service code point Aix.
Similarly, the mL2TP peers may set up a call supporting different loss priority classes, i.e., with differentiated service code points Axj, j = 1, 2, 3, as shown in the table, below.
Aix Differentiated Service Code Point Value Axl X010 Ax2 ~ 100 Ax3 X110 Loss Priority Classes Thus, for AF services, differentiated service code point values such as OOlxxx or xxx010 are acceptable for the various classes. (For proper traffic engineering, it is required that the two mL2TP peers specify a rate for each tunnel that supports AF
services. With such specification, the L2TP peers can decide when to admit/reject data sessions. They can also decide how to share the available resources (bandwidth and buffers) among the different established tunnels. Similarly, for the earlier-mentioned Expedited Forwarding (EF) service, the QoS Request AVP includes the EF Code Point (i.e., the differentiated service code point value), and the requested average rate.) The presence of a QoS Request AVP in the ICRQ or OCRQ indicates that one mL2TP peer wishes to use several differentiated service code points for all data packets of a particular PPP call. If the mL2TP peer cannot accept any code point due to a shortage of resources, that mL2TP peer can recommend an alternative code point if the above-mentioned Promotable/Demotable bits are set. Otherwise, the mL2TP peer rejects the call request. Thus, the value found in the QoS Grant AVP (described below) indicates the value that the mL2TP peer is willing to accept.
In addition, the QoS Request AVP contains other parameters that allow further specification of traffic parameters for a particular class. In FIG. 5, only QoS2 is shown as specifying additional parameters. The requested rate field, tolerable burst size field, optional excess burst size field, peak rate field and optional loss/delay requirement field represent trai~c parameters that are used to provide a class within a call with quantitative delay/loss guarantees as well as improve call admission probability (increase bandwidth multiplexing). In particular, the requested rate field value represents the requested average bits per second for that class. The tolerable burst size field value request represents how long a transmitter may transmit packets at the peak rate. The excess burst size field value request represents how long a transmitter can exceed the tolerable burst size. The peak field value request represents the requested peak rate, e.g., in bits per second. The loss/delay requirement field value request represents either packet loss (above-mentioned L bit field is set) or delay class (above-mentioned D bit field is set). For packet loss, this value represents the percentage of tolerable packet loss, e.g., 1%, 5%, etc. For delay class, this value represents the tolerable delay, e.g., in milli-seconds.
FIG. 6 shows an illustrative format for a QoS Grant AVP sent by a tunnel terminator (e.g., LNS 135 of FIG. 2) in the ICRP message. The fields of the QoS Grant AVP are complementary to those of the QoS Request AVP (described above). In this case, there are no D or L bits, and the responding server indicates the "Granted Rate" and the Guarantee Loss/Delay value (optional) in the indicated fields. The granted rate may be smaller than the requested rate. (At this point, it should be noted that if multiple QoS
need to be negotiated in the reverse direction, then the LNS will also attach a QoS
Request AVP in accordance with the inventive concept to the ICRP message (not shown).
In this case, the ICCN reply from the LAC carries the QoS Reply AVP to the LNS
request.) A corresponding illustrative control message transaction for performing the above-described negotiation is shown in FIG. 7 between two mL2TP peers (here represented by a LAC and an LNS) when the LNS is providing the call request. In this instance, the corresponding Outgoing-Call-Request (OCRQ), Outgoing-Call-Reply (OCRP) and Outgoing-Call-Connected (OCCN) messages are suitably modified as described above.
' As can be observed from the above, a flexible quality of service extension to L2TP
to support multi-class extension to multilink PPP has been described. As a result, only one sequence number set need be used for payload messages notwithstanding the payloads represent different classes of service. This is illustrated in FIG. 8. Only one session is established. L2TP packet 20 has a defined quality-of service field as represented by ToS 1.
This field is followed by an L2TP sequence number field, illustratively set to 1. L2TP
packet 21, which conveys the next class 1 packet, uses the same sequence number set as L2TP packet 20 and the value for this field is simply the next number in the sequence, I.e., 2. However, and in accordance with the inventive concept, when a different class of PPP
data is encountered, the same sequence numbering space, or sequence number set, is used.
This is illustrated by L2TP packet 22, which conveys PPP data having an MP
class 2 and using the next number in the sequence, I. e., 3.
Turning briefly to FIG. 9, a high-level block diagram of a representative NAS
(L2TP peer), or packet server, is shown in accordance with the principles of the invention.
A packet server is a stored-program-control based processor architecture and includes processor 650, memory 660 (for storing program instructions and data, e.g., for communicating the above-mentioned new AVP messages related to QoS, etc.) and communications interfaces) 665 for coupling to one or more communication facilities as represented by path 666. It should be noted that each LAC maintains as many priority queues per-call, or per-session, as specified in the ICRQ QoS Request AVP.
(Buffers of other sessions are not shown.) In accordance with the invention, only one sequence number set is used per-call for the bearer data channel. Packets for each queue can be served using a strict priority scheduling algorithm or weighted fair-queuing type of scheduling algorithms. The different queues are illustrated in FIG. 9 by QoS 1 queue and QoS2 queue of memory 660.
As such, differentiated services can be offered by ISPs within a call. For example, assume that ISP A of FIG. 2 offers three data services: gold (for voice-over-IP), silver (for urgent data), and bronze (for regular data). Each user can subscribe to any of the three data services. In addition, each user can specify whether that user wants Internet or corporate network access or mixed services. Further, the user can specify a certain ' bandwidth the user wishes to use for a particular data service e.g., gold at 8 Kbps, silver at 56 Kbps via, e.g., their a priori stored profile (not shown).
It should be noted that the inventive concept is also applicable to providing Guaranteed/Differentiated Services in other networks. As an example, an illustrative wide area wireless data network in accordance with the principles of the invention is shown in FIG. 10. Other than the inventive concept, the elements are well-known and will not be described in detail. For example, the mobile endpoint, or mobile node (MN), is represented by MN 905. The latter is coupled to base station (BS) 910. For the purposes of this example, it is assumed that the BS 910 is a part of a "foreign area"
served by intermediate foreign agent (IFA) 915, which includes a policy server (not shown). IFA
915 is coupled to gateway foreign agent/dynamic home agent (GFA/DHA) 920.
Similarly, the user (not shown) of MN 905 is associated with a "home area." The latter is represented by gateway home agent (GHA) 925 and home agent (HA) 930. It is assumed that well-known user authentication methods are used, e.g., via Authentication, Authorization, Accounting (AAA) Servers (not shown). In this context, BS 910, IFA
915, GFA 920, GHA 925 and HA 930 are all different forms of packet servers.
Communications between, e.g., GFA/I-g'A 920 and GHA 925, is via IP-based network 940.
Except as modified by the inventive concept, the communications system of FIG.
10 uses the Mobile IP protocol, which is designed to allow a mobile node to have connectivity on the move (e.g., see C. Perkins et al., "1P mobility support,"
RFC2002, Oct 1996). As such, only that part of the Mobile IP protocol as modified by the inventive concept is described herein.
In Mobile IP, MN 905 registers with BS 910 via link-layer messaging (not shown).
In particular, MN 905 transmits a Registration Request message to BS 910, which uses link-layer signaling to communicate the request to IFA 915. Then, IFA 915 relays the mobile IP Registration Request message to a GFA 920, after modifying relevant fields.
Subsequently, a "compound tunnel" is then set up between the home agent (e.g., HA 930) and the foreign agent (e.g., IFA 915), on behalf of the mobile node (e.g., MN
905) (e.g., see S. Blake et al., "An architecture for differentiated services," RFC2475 Dec 1998). (It ' should be noted that if network-layer signaling is used, the compound tunnel is from BS
910 to HA 930. In either case, the inventive concept equally applies.) Although some proposals have been made to provide QoS in Mobile IP, currently, traffic from a mobile node is carried as best ei~ort traffic in the Mobile IP
tunnel as IP-in-IP. (An example of such a QoS proposal can be found in "1P encapsulation in IP," by C.
Perkins, RFC2003, Oct 1996, which proposes a framework for providing quality of service based on a 6 bit code point present in the TOS byte. Also, the above-mentioned article by Blake et al. describes marking the TOS byte of the outer IP header with the same value as that present in the inner IP header.) However, and in accordance with the inventive concept, a new QoS Request extension is included in this Mobile IP Registration Request message. This new QoS Request extension allows a user to request multiple QoS within the same session. In addition, the approach also allows difFerent segments of a compound tunnel to enjoy different by related QoS. (For the purposes of this description it is assumed that only the end points of each segment are responsible for the QoS that they agree to guarantee.) In accordance with the invention, when MN 905 first registers with BS 910, MN 905 attaches a QoS Request extension in its Registration Request message (referred to herein as a modified Registration Request message). This QoS Request extension allows a user to request as many classes of QoS for its connection as it deems necessary. At each level, the corresponding mobility agent (e.g., BA, IFA etc.) may modify this QoS
Request extension if it cannot provide sufficient resources to grant the requested QoS. For example, GFA 920 decides (based on available resources and the user's request) whether to admit the user or not. If the user's request is accepted, i.e., the user is admitted, GFA
920 forwards the modified Registration Request message to GHA 925. (GFA 920 can also choose a new but related code point (based on the ability to "promote" or "demote"
the service) if the network of FIG. 10 is currently experiencing congestion for the segment between GFA 920 and GHA 925.) When GFA 920 receives a positive reply from GHA
925, GFA 920 stores this information in its local policy server (not shown) or its associated AAA server (not shown). GFA 920 then attaches the granted QoS
extension to the lower-level mobility agents. Lower-level mobility agents may store the QoS
' information in their local policy server (not shown). (It should be noted that such storage may be as simple as storing the information as an entry in a cached registration table.) The QoS Request extension thus allows specification of differentiated service (DS) code points (or classes of DS code points) that MN 905 desires, and some optional traffic parameters for a single call. Illustrative formats for the QoS Request extension and QoS Request reply are shown in FIGs. 11 and 12 for use in the Registration Request message and Reply message of Mobile IP. Note that the tunnel and call identifiers can be in the QoS Request extension and/or in the QoS Reply extension. Those identifiers are later used for bearer data in a GRE (generic routing and encapsulation) tunnel. Bearer data for a particular QoS class will use the appropriate ToS codepoint in the IP ToS byte.
In a similar fashion to the AVP messages shown in FIGS. 5 and 6, the QoS
Request extension and the QoS Reply extension include a "number of classes" field.
Each requested class is expressed in a corresponding ToS byte (e.g., ToS 1, ToS2, etc.) Each ToS byte includes P and M bits. Optional Traffic parameters for each class are also shown (as such, the number of classes field also specifies the number of optional parameters included in the message). (However, these optional traffic parameters can be alternatively stored as part of the user profile in an AAA server (not shown).) The presence of optional traffic parameters allow more flexibility in terms of services that can be sold to customers as well as smarter admission control algorithms that provide better bandwidth multiplexing gain. In the QoS Reply extension, the code field is used to indicate whether the QoS Request is granted or rejected.
Another modification to Mobile IP Registration and Reply messages is shown in FIG. 13. Mobile IP Registration message 60 comprises additional "service option" fields, each with an associated QoS. The "service option" field conveys a request for the type of service, e.g., Internet access, VPN, mixed (e.g., both Internet and VPN).
Similarly, there is a corresponding Mobile IP Registration Reply message as indicated by Mobile IP
Registration Reply message 61.
The foregoing merely illustrates the principles of the invention and it will thus be appreciated that those skilled in the art will be able to devise numerous alternative arrangements which, although not explicitly described herein, embody the principles of the invention and are within its spirit and scope. For example, although the inventive concept was described in the context of a Serving LAC tunneling to an LNS, the inventive concept is applicable to mufti-hop tunnels, e.g., such as described in U.S. Patent No. 6,449,472 which issued on September 10, 2002.
messages. (In the former case, the LAC (or LNS) communicates with a respective Authentication Authorization and Accounting (AAA) server, as known in the art, to obtain user profiles based on, e.g., user login name. However, for the remainder of this description, the inventive concept is described in the context of an incoming call to LAC
155 using MP.) In support of the above-described virtual dial up service, and in accordance with the inventive concept, a form of the L2TP (mL2TP) protocol is used. As in L2TP, there are two parallel components of mL2TP operating over a given tunnel: control messages between each LAC-LNS pair, and payload packets between the same LAC-LNS pair.
The latter are used to transport mL2TP encapsulated MP packets for user data sessions between the LAC-LNS pair. As in L2TP, the Nr (Next Received) and Ns (Next Sent) fields are always present in control messages and are optionally present in payload packets. The control messages and payload messages use different sequence number sets.
For the above-mentioned LAC-LNS pair scenario, there are no changes to the L2TP draft protocol definition as far as the maintenance and usage of (Nr, Ns) is concerned.
As noted above, before the call is established, mL2TP control messages are exchanged between the Serving LAC and the LNS. Therefore, new Attribute Value Pairs (AVP)s (described below) are defined for use in the L2TP control messages (hence becoming mL2TP control messages) for enabling two mL2TP peers to set up, or negotiate, a call having multiple classes of service. As such, it should be realized that -other than the additional QoS negotiation for establishing such a call - L2TP
tunnel set up procedures are unchanged.
Reference should now be made to FIG. 3, which shows an illustrative high-level flow chart of a method in accordance with the principles of the invention for negotiating multiple QoS within a single call. (It is presumed that LAC 155 and the other respective servers are suitably programmed to carry out the below-described methods using conventional programming techniques, which, as such, will not be described herein.) In step 305 of FIG. 3, the serving LAC receives one PPP LCP frame with a multilink header -$-from the user. Upon identification of the multilink header, the serving LAC
(e.g., LAC
' 155), examines the "# Susp Clses" field of the multilink header. In particular, the serving LAC checks the value of the "# of Susp Clses" field and the associated values of the ToS
values within the modified multilink header and creates an appropriate QoS
Request AVP
S for attachment to an ICRQ message (described below). (As known in the art, the "# Susp Clses" field is currently available in a multilink header. Therefore, and, in accordance with the inventive concept, a multilink header is modified as shown in FIG. 14 to convey additional QoS information (in FIG. 14, illustratively 3 ToS.) In step 315, the serving LAC transmits the ICRQ message with the QoS Request AVP. In accordance with the inventive concept, the QoS Request AVP specifies how many QoS classes are associated with this call and the types of QoS (described further below). The serving LAC, in step 320, receives a reply with a QoS Reply AVP in the received ICRP message. The serving LAC then responds with an Incoming-Call-Connected (ICCN) message in step 325.
A
corresponding illustrative control message transaction for performing the above-described negotiation is shown in FIG. 4 between two mL2TP peers (here represented by a LAC and an LNS).
Turning to FIG. 5, an illustrative format of a QoS Request AVP is shown. The first four bits of this AVP have a predefined bit pattern of "1100" (as defined L2TP), bit positions 4 and 5 are "don't cares," and bit positions 6 and 7 convey two new parameters, D, and L, where D is representative of a delay class bit, and L is representative of a Loss class. The D bit is used if the underlying tunnel supports delay classes only.
In other words, if the D bit is set in an ICRQ message, only the delay bits of the differentiated code point value are taken into consideration (described below). Similarly, the L
bit is used if the underlying tunnel supports loss classes only, i.e., if the L bit is set only the loss bits of the code point are taken into consideration.
Following the D and L bits is a eight bit length field, the value for which is the size of this AVP. After the length field, there is a two byte Vendor specific ID
(here illustratively shown as conveying the data representative of a Lucent identifier (Lucentid) and also denoting that this is a call message having multiple QoS).
(Alternatively, this could be replaced by a predefined mL2TP AVP code signifying that this is a call message having multiple QoS.) The Vendor specific ID is followed by a two byte L2TP
attribute type field, here set to 1. After the attribute field there is a "number of classes" field that specifies the number of QoS being requested. In this example, the number of classes field is equal to the number of different classes determined in step and 305 of FIG.
3.
Following the number of classes field, there are as many differentiated services code point values (QoS identifiers that are one byte in length) as are specified by the value of the number of classes field. (For the QoS Request AVP of FIG. 5, the value of the number of classes field is illustratively three.) Each QoS specifies a particular class of differentiated service for an associated PPP class extension. In addition, the first two bits of each QoS bytes are representative of a promotable bit, P, and a demotable bit, M. In other words, the P and M bits are used on a per-class basis. When the P and M
bits represent a zero value, the mL2TP peer is indicating that only the chosen differentiated code point value is to be used on IP packets within the session's data channel for that class. When the P bit is set, it means that the mL2TP peer can recommend a differentiated service code point value with a higher level of service if the requested one is not available for a class. When the M bit is set, it means that the mL2TP peer can recommend a differentiated service code point value with a lower level of service should the requested one not be available for a class. Following the multiple QoS fields, a "padding" field is used to fill the AVP message, if necessary.
The values of the differentiated service code point values are defined in a fashion similar to the definition of codepoints in the above-mentioned Assured Forwarding (AF) Service. In particular, the two mL2TP peers may set up classes A;~ with a call, where i represents a type of delay class and j represents a type of loss class. For the purposes of example only, i = l, 2, 3, 4; and j = 1, 2, 3. As such, there are 4 classes for a call each class supporting a different delay priority class, i.e., with differentiated service code points Aix, i = l, 2, 3, 4, as shown in the table, below.
Aix Differentiated Service Code Point Value Alx OO1XXX
A2x O 10~
A3x 011 A4x ~ 100 Delay Priority Classes The "X" represents a "don't care" condition, i.e., the value can be a binary zero or a binary one. Individual sessions with differentiated service code points Aij are mapped to a tunnel supporting differentiated service code point Aix.
Similarly, the mL2TP peers may set up a call supporting different loss priority classes, i.e., with differentiated service code points Axj, j = 1, 2, 3, as shown in the table, below.
Aix Differentiated Service Code Point Value Axl X010 Ax2 ~ 100 Ax3 X110 Loss Priority Classes Thus, for AF services, differentiated service code point values such as OOlxxx or xxx010 are acceptable for the various classes. (For proper traffic engineering, it is required that the two mL2TP peers specify a rate for each tunnel that supports AF
services. With such specification, the L2TP peers can decide when to admit/reject data sessions. They can also decide how to share the available resources (bandwidth and buffers) among the different established tunnels. Similarly, for the earlier-mentioned Expedited Forwarding (EF) service, the QoS Request AVP includes the EF Code Point (i.e., the differentiated service code point value), and the requested average rate.) The presence of a QoS Request AVP in the ICRQ or OCRQ indicates that one mL2TP peer wishes to use several differentiated service code points for all data packets of a particular PPP call. If the mL2TP peer cannot accept any code point due to a shortage of resources, that mL2TP peer can recommend an alternative code point if the above-mentioned Promotable/Demotable bits are set. Otherwise, the mL2TP peer rejects the call request. Thus, the value found in the QoS Grant AVP (described below) indicates the value that the mL2TP peer is willing to accept.
In addition, the QoS Request AVP contains other parameters that allow further specification of traffic parameters for a particular class. In FIG. 5, only QoS2 is shown as specifying additional parameters. The requested rate field, tolerable burst size field, optional excess burst size field, peak rate field and optional loss/delay requirement field represent trai~c parameters that are used to provide a class within a call with quantitative delay/loss guarantees as well as improve call admission probability (increase bandwidth multiplexing). In particular, the requested rate field value represents the requested average bits per second for that class. The tolerable burst size field value request represents how long a transmitter may transmit packets at the peak rate. The excess burst size field value request represents how long a transmitter can exceed the tolerable burst size. The peak field value request represents the requested peak rate, e.g., in bits per second. The loss/delay requirement field value request represents either packet loss (above-mentioned L bit field is set) or delay class (above-mentioned D bit field is set). For packet loss, this value represents the percentage of tolerable packet loss, e.g., 1%, 5%, etc. For delay class, this value represents the tolerable delay, e.g., in milli-seconds.
FIG. 6 shows an illustrative format for a QoS Grant AVP sent by a tunnel terminator (e.g., LNS 135 of FIG. 2) in the ICRP message. The fields of the QoS Grant AVP are complementary to those of the QoS Request AVP (described above). In this case, there are no D or L bits, and the responding server indicates the "Granted Rate" and the Guarantee Loss/Delay value (optional) in the indicated fields. The granted rate may be smaller than the requested rate. (At this point, it should be noted that if multiple QoS
need to be negotiated in the reverse direction, then the LNS will also attach a QoS
Request AVP in accordance with the inventive concept to the ICRP message (not shown).
In this case, the ICCN reply from the LAC carries the QoS Reply AVP to the LNS
request.) A corresponding illustrative control message transaction for performing the above-described negotiation is shown in FIG. 7 between two mL2TP peers (here represented by a LAC and an LNS) when the LNS is providing the call request. In this instance, the corresponding Outgoing-Call-Request (OCRQ), Outgoing-Call-Reply (OCRP) and Outgoing-Call-Connected (OCCN) messages are suitably modified as described above.
' As can be observed from the above, a flexible quality of service extension to L2TP
to support multi-class extension to multilink PPP has been described. As a result, only one sequence number set need be used for payload messages notwithstanding the payloads represent different classes of service. This is illustrated in FIG. 8. Only one session is established. L2TP packet 20 has a defined quality-of service field as represented by ToS 1.
This field is followed by an L2TP sequence number field, illustratively set to 1. L2TP
packet 21, which conveys the next class 1 packet, uses the same sequence number set as L2TP packet 20 and the value for this field is simply the next number in the sequence, I.e., 2. However, and in accordance with the inventive concept, when a different class of PPP
data is encountered, the same sequence numbering space, or sequence number set, is used.
This is illustrated by L2TP packet 22, which conveys PPP data having an MP
class 2 and using the next number in the sequence, I. e., 3.
Turning briefly to FIG. 9, a high-level block diagram of a representative NAS
(L2TP peer), or packet server, is shown in accordance with the principles of the invention.
A packet server is a stored-program-control based processor architecture and includes processor 650, memory 660 (for storing program instructions and data, e.g., for communicating the above-mentioned new AVP messages related to QoS, etc.) and communications interfaces) 665 for coupling to one or more communication facilities as represented by path 666. It should be noted that each LAC maintains as many priority queues per-call, or per-session, as specified in the ICRQ QoS Request AVP.
(Buffers of other sessions are not shown.) In accordance with the invention, only one sequence number set is used per-call for the bearer data channel. Packets for each queue can be served using a strict priority scheduling algorithm or weighted fair-queuing type of scheduling algorithms. The different queues are illustrated in FIG. 9 by QoS 1 queue and QoS2 queue of memory 660.
As such, differentiated services can be offered by ISPs within a call. For example, assume that ISP A of FIG. 2 offers three data services: gold (for voice-over-IP), silver (for urgent data), and bronze (for regular data). Each user can subscribe to any of the three data services. In addition, each user can specify whether that user wants Internet or corporate network access or mixed services. Further, the user can specify a certain ' bandwidth the user wishes to use for a particular data service e.g., gold at 8 Kbps, silver at 56 Kbps via, e.g., their a priori stored profile (not shown).
It should be noted that the inventive concept is also applicable to providing Guaranteed/Differentiated Services in other networks. As an example, an illustrative wide area wireless data network in accordance with the principles of the invention is shown in FIG. 10. Other than the inventive concept, the elements are well-known and will not be described in detail. For example, the mobile endpoint, or mobile node (MN), is represented by MN 905. The latter is coupled to base station (BS) 910. For the purposes of this example, it is assumed that the BS 910 is a part of a "foreign area"
served by intermediate foreign agent (IFA) 915, which includes a policy server (not shown). IFA
915 is coupled to gateway foreign agent/dynamic home agent (GFA/DHA) 920.
Similarly, the user (not shown) of MN 905 is associated with a "home area." The latter is represented by gateway home agent (GHA) 925 and home agent (HA) 930. It is assumed that well-known user authentication methods are used, e.g., via Authentication, Authorization, Accounting (AAA) Servers (not shown). In this context, BS 910, IFA
915, GFA 920, GHA 925 and HA 930 are all different forms of packet servers.
Communications between, e.g., GFA/I-g'A 920 and GHA 925, is via IP-based network 940.
Except as modified by the inventive concept, the communications system of FIG.
10 uses the Mobile IP protocol, which is designed to allow a mobile node to have connectivity on the move (e.g., see C. Perkins et al., "1P mobility support,"
RFC2002, Oct 1996). As such, only that part of the Mobile IP protocol as modified by the inventive concept is described herein.
In Mobile IP, MN 905 registers with BS 910 via link-layer messaging (not shown).
In particular, MN 905 transmits a Registration Request message to BS 910, which uses link-layer signaling to communicate the request to IFA 915. Then, IFA 915 relays the mobile IP Registration Request message to a GFA 920, after modifying relevant fields.
Subsequently, a "compound tunnel" is then set up between the home agent (e.g., HA 930) and the foreign agent (e.g., IFA 915), on behalf of the mobile node (e.g., MN
905) (e.g., see S. Blake et al., "An architecture for differentiated services," RFC2475 Dec 1998). (It ' should be noted that if network-layer signaling is used, the compound tunnel is from BS
910 to HA 930. In either case, the inventive concept equally applies.) Although some proposals have been made to provide QoS in Mobile IP, currently, traffic from a mobile node is carried as best ei~ort traffic in the Mobile IP
tunnel as IP-in-IP. (An example of such a QoS proposal can be found in "1P encapsulation in IP," by C.
Perkins, RFC2003, Oct 1996, which proposes a framework for providing quality of service based on a 6 bit code point present in the TOS byte. Also, the above-mentioned article by Blake et al. describes marking the TOS byte of the outer IP header with the same value as that present in the inner IP header.) However, and in accordance with the inventive concept, a new QoS Request extension is included in this Mobile IP Registration Request message. This new QoS Request extension allows a user to request multiple QoS within the same session. In addition, the approach also allows difFerent segments of a compound tunnel to enjoy different by related QoS. (For the purposes of this description it is assumed that only the end points of each segment are responsible for the QoS that they agree to guarantee.) In accordance with the invention, when MN 905 first registers with BS 910, MN 905 attaches a QoS Request extension in its Registration Request message (referred to herein as a modified Registration Request message). This QoS Request extension allows a user to request as many classes of QoS for its connection as it deems necessary. At each level, the corresponding mobility agent (e.g., BA, IFA etc.) may modify this QoS
Request extension if it cannot provide sufficient resources to grant the requested QoS. For example, GFA 920 decides (based on available resources and the user's request) whether to admit the user or not. If the user's request is accepted, i.e., the user is admitted, GFA
920 forwards the modified Registration Request message to GHA 925. (GFA 920 can also choose a new but related code point (based on the ability to "promote" or "demote"
the service) if the network of FIG. 10 is currently experiencing congestion for the segment between GFA 920 and GHA 925.) When GFA 920 receives a positive reply from GHA
925, GFA 920 stores this information in its local policy server (not shown) or its associated AAA server (not shown). GFA 920 then attaches the granted QoS
extension to the lower-level mobility agents. Lower-level mobility agents may store the QoS
' information in their local policy server (not shown). (It should be noted that such storage may be as simple as storing the information as an entry in a cached registration table.) The QoS Request extension thus allows specification of differentiated service (DS) code points (or classes of DS code points) that MN 905 desires, and some optional traffic parameters for a single call. Illustrative formats for the QoS Request extension and QoS Request reply are shown in FIGs. 11 and 12 for use in the Registration Request message and Reply message of Mobile IP. Note that the tunnel and call identifiers can be in the QoS Request extension and/or in the QoS Reply extension. Those identifiers are later used for bearer data in a GRE (generic routing and encapsulation) tunnel. Bearer data for a particular QoS class will use the appropriate ToS codepoint in the IP ToS byte.
In a similar fashion to the AVP messages shown in FIGS. 5 and 6, the QoS
Request extension and the QoS Reply extension include a "number of classes" field.
Each requested class is expressed in a corresponding ToS byte (e.g., ToS 1, ToS2, etc.) Each ToS byte includes P and M bits. Optional Traffic parameters for each class are also shown (as such, the number of classes field also specifies the number of optional parameters included in the message). (However, these optional traffic parameters can be alternatively stored as part of the user profile in an AAA server (not shown).) The presence of optional traffic parameters allow more flexibility in terms of services that can be sold to customers as well as smarter admission control algorithms that provide better bandwidth multiplexing gain. In the QoS Reply extension, the code field is used to indicate whether the QoS Request is granted or rejected.
Another modification to Mobile IP Registration and Reply messages is shown in FIG. 13. Mobile IP Registration message 60 comprises additional "service option" fields, each with an associated QoS. The "service option" field conveys a request for the type of service, e.g., Internet access, VPN, mixed (e.g., both Internet and VPN).
Similarly, there is a corresponding Mobile IP Registration Reply message as indicated by Mobile IP
Registration Reply message 61.
The foregoing merely illustrates the principles of the invention and it will thus be appreciated that those skilled in the art will be able to devise numerous alternative arrangements which, although not explicitly described herein, embody the principles of the invention and are within its spirit and scope. For example, although the inventive concept was described in the context of a Serving LAC tunneling to an LNS, the inventive concept is applicable to mufti-hop tunnels, e.g., such as described in U.S. Patent No. 6,449,472 which issued on September 10, 2002.
Claims (10)
1. A method for use in a virtual private network (VPN) for establishing multiple quality of service (QoS) classes using a Layer Two Tunnel Protocol (L2TP) for a call between a first packet server and a second packet server, the method comprising the steps of:
determining that the call needs to be established directly between the first packet server and the second packet server using a packet tunnel; and establishing the call through the packet tunnel by first negotiating multiple QoS
classes for the call by sending, to the second packet server, a QoS request message comprising a number of classes field whose value represents the number of classes of service requested in the QoS request message and receiving, from the second packet server, a QoS grant message that includes classes granted of service information.
determining that the call needs to be established directly between the first packet server and the second packet server using a packet tunnel; and establishing the call through the packet tunnel by first negotiating multiple QoS
classes for the call by sending, to the second packet server, a QoS request message comprising a number of classes field whose value represents the number of classes of service requested in the QoS request message and receiving, from the second packet server, a QoS grant message that includes classes granted of service information.
2. The method of claim 1, wherein each different class of quality of service QoS
corresponds to an associated point-to-point protocol multi-class extension for the call.
corresponds to an associated point-to-point protocol multi-class extension for the call.
3. The method of claim 1, wherein the QoS request message further comprises parameters that include a promotable bit that enables the second packet server to recommend a higher class of service for a class than the requested class of service.
4. The method of claim 1, wherein the QoS request message further comprises parameters that include a demotable bit that enables the second packet server to recommend a lower class of service for a class than the requested class of service.
5. The method of claim 1, wherein the QoS request message is a part of a Registration Request message used in a Mobile Internet Protocol.
6. The method of claim 1, wherein the QoS grant message include a granted rate field, a tolerable burst size field, an excess burst size field, and a peak rate field.
7. The method of claim 1, wherein the first packet server communicates Internet Protocol (IP) packets, and the method further comprises the step of first establishing a multilink point-to-point protocol connection with a user associated with the call, wherein the multilink point-to-point protocol has multi-class extensions.
8. The method of claim 7, wherein the establishing step includes the step of sending, to the second packet server, a Layer Two Tunneling Protocol (L2TP) Attribute Value Pair message comprising a number of classes field whose value is equal to the number of different classes of the multilink point-to-point protocol connection.
9. A method for use in a Layer Two Transport Protocol (L2TP) access server (LAC) within a virtual private network for establishing multiple quality of service (QoS) classes for a call, the method comprising the steps of receiving a packet formatted in accordance with a point-to-point protocol with multi-class extensions, wherein the received packet includes a first number-of classes field that comprises a value equal to the multiple QoS classes for the call from a user; and negotiating a call using a Layer Two Tunneling Protocol (L2TP) type message directly with a L2TP network server (LNS) by attaching a L2TP Attribute Value Pair message comprising a second number-of classes field whose value is equal to the value of the first number-of classes field to an L2TP control message and transmitting the L2TP
control message to the LNS.
control message to the LNS.
10. A method for use in a packet server for negotiating multiple quality of service (QoS) classes for a particular call within a same session, the method comprising the steps of:
attaching a quality of service request to a mobile Internet protocol (IP) registration request; and transmitting the mobile IP registration request and the attached QoS request to another packet server;
wherein the quality of service request comprises a value specifying a number of QoS classes for the call and associated QoS service fields relating to each QoS class associated with the particular call during the same session.
attaching a quality of service request to a mobile Internet protocol (IP) registration request; and transmitting the mobile IP registration request and the attached QoS request to another packet server;
wherein the quality of service request comprises a value specifying a number of QoS classes for the call and associated QoS service fields relating to each QoS class associated with the particular call during the same session.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/285,817 US6654808B1 (en) | 1999-04-02 | 1999-04-02 | Proving quality of service in layer two tunneling protocol networks |
| US09/285,817 | 1999-04-02 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2300758A1 CA2300758A1 (en) | 2000-10-02 |
| CA2300758C true CA2300758C (en) | 2004-06-29 |
Family
ID=23095822
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002300758A Expired - Fee Related CA2300758C (en) | 1999-04-02 | 2000-03-16 | Providing quality of service in layer two tunneling protocol networks |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US6654808B1 (en) |
| EP (1) | EP1041792B8 (en) |
| JP (1) | JP3737668B2 (en) |
| AT (1) | ATE492095T1 (en) |
| CA (1) | CA2300758C (en) |
| DE (1) | DE60045355D1 (en) |
Families Citing this family (38)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10511573B2 (en) * | 1998-10-30 | 2019-12-17 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
| US8266266B2 (en) | 1998-12-08 | 2012-09-11 | Nomadix, Inc. | Systems and methods for providing dynamic network authorization, authentication and accounting |
| US7194554B1 (en) | 1998-12-08 | 2007-03-20 | Nomadix, Inc. | Systems and methods for providing dynamic network authorization authentication and accounting |
| US8713641B1 (en) | 1998-12-08 | 2014-04-29 | Nomadix, Inc. | Systems and methods for authorizing, authenticating and accounting users having transparent computer access to a network using a gateway device |
| US6577644B1 (en) * | 1999-06-22 | 2003-06-10 | Lucent Technologies Inc. | Quality of service (QoS) enhancement to multilink point-to-point protocol (PPP) |
| US6922404B1 (en) * | 1999-10-14 | 2005-07-26 | Nortel Networks Limited | Mobile IP extensions rationalization (MIER) |
| EP1819108B1 (en) * | 1999-10-22 | 2013-09-18 | Nomadix, Inc. | Systems and methods for dynamic bandwidth management on a per subscriber basis in a communication network |
| US6853621B1 (en) * | 2000-01-18 | 2005-02-08 | Go2Call.Com, Inc. | System and method for selecting a packet-switched telephony service provider |
| JP3855595B2 (en) * | 2000-04-25 | 2006-12-13 | 株式会社日立製作所 | COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND COMMUNICATION DEVICE |
| US7111163B1 (en) | 2000-07-10 | 2006-09-19 | Alterwan, Inc. | Wide area network using internet with quality of service |
| JP2002057698A (en) * | 2000-08-09 | 2002-02-22 | Fujitsu Ltd | Packet data processor |
| US7054321B1 (en) * | 2000-10-27 | 2006-05-30 | Redback Networks Inc. | Tunneling ethernet |
| US20020062379A1 (en) * | 2000-11-06 | 2002-05-23 | Widegren Ina B. | Method and apparatus for coordinating quality of service requirements for media flows in a multimedia session with IP bearer services |
| US20020085563A1 (en) * | 2001-01-03 | 2002-07-04 | Michael Mesh | Packet processing method and engine |
| KR100387044B1 (en) * | 2001-02-01 | 2003-06-12 | 삼성전자주식회사 | Method for providing packet call service in radio telecommunication system |
| US6950862B1 (en) * | 2001-05-07 | 2005-09-27 | 3Com Corporation | System and method for offloading a computational service on a point-to-point communication link |
| US6816890B2 (en) * | 2001-05-28 | 2004-11-09 | Hitachi, Ltd. | Gateway apparatus with LAC function |
| US7339908B2 (en) * | 2001-07-31 | 2008-03-04 | Arraycomm, Llc. | System and related methods to facilitate delivery of enhanced data services in a mobile wireless communications environment |
| US7363376B2 (en) * | 2001-07-31 | 2008-04-22 | Arraycomm Llc | Method and apparatus for generating an identifier to facilitate delivery of enhanced data services in a mobile computing environment |
| US7225236B1 (en) * | 2001-08-07 | 2007-05-29 | 3Com Corporation | Load balancing between LNSs using virtual LNS with minimal LAC configuration |
| JP3831656B2 (en) * | 2001-12-05 | 2006-10-11 | 株式会社日立製作所 | Network connection device and network connection method |
| KR100834671B1 (en) * | 2002-01-18 | 2008-06-02 | 삼성전자주식회사 | Data service method for mobile communication system |
| KR100438431B1 (en) * | 2002-02-23 | 2004-07-03 | 삼성전자주식회사 | Security system for virtual private network service access in communication network and method thereof |
| US7272122B2 (en) * | 2002-04-26 | 2007-09-18 | Nokia Corporation | Relocation of application-specific functionality during seamless network layer-level handoffs |
| US7224673B1 (en) * | 2002-05-24 | 2007-05-29 | Cisco Technology, Inc. | Mobile IP registration message compression |
| US6985488B2 (en) * | 2003-01-15 | 2006-01-10 | Ciena Corporation | Method and apparatus for transporting packet data over an optical network |
| US7024687B2 (en) * | 2003-05-21 | 2006-04-04 | Cisco Technology, Inc. | System and method for providing end to end authentication in a network environment |
| US7724700B1 (en) * | 2003-08-25 | 2010-05-25 | Cisco Technology, Inc. | Application server-centric quality of service management in network communications |
| US20060171365A1 (en) * | 2005-02-02 | 2006-08-03 | Utstarcom, Inc. | Method and apparatus for L2TP dialout and tunnel switching |
| US7797427B2 (en) * | 2005-12-13 | 2010-09-14 | Cisco Technology, Inc. | System and method for applying a communication feature extension |
| US20080240053A1 (en) * | 2007-03-27 | 2008-10-02 | Oswal Anand K | Quality of service (QoS) negotiation between network nodes in a Mobile IP network |
| US8310924B2 (en) * | 2008-05-15 | 2012-11-13 | Telefonaktiebolaget L M Ericsson (Publ) | Method and apparatus for providing QoS for MP subscribers at the subscriber level |
| CN102461253B (en) * | 2009-04-17 | 2014-12-10 | 黑莓有限公司 | Mechanisms for evolved packet system quality of service class identifier extension |
| JP4802263B2 (en) * | 2009-07-17 | 2011-10-26 | 株式会社日立製作所 | Encrypted communication system and gateway device |
| SG192006A1 (en) | 2011-01-18 | 2013-08-30 | Nomadix Inc | Systems and methods for group bandwidth management in a communication systems network |
| CN103701710B (en) | 2013-12-20 | 2017-01-11 | 杭州华为数字技术有限公司 | Data transmission method, core forwarding equipment and endpoint forwarding equipment |
| CN111279744B (en) * | 2017-10-26 | 2023-07-18 | 华为技术有限公司 | Quality of service negotiation technique |
| CN114615107A (en) * | 2020-11-23 | 2022-06-10 | 华为技术有限公司 | Method and device for establishing communication |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| ZA946674B (en) * | 1993-09-08 | 1995-05-02 | Qualcomm Inc | Method and apparatus for determining the transmission data rate in a multi-user communication system |
| US5674003A (en) * | 1995-04-28 | 1997-10-07 | Andersen; David B. | Mechanisms for accessing unique features of telephony networks from a protocol-Independent data transport interface |
| US5917822A (en) * | 1995-11-15 | 1999-06-29 | Xerox Corporation | Method for providing integrated packet services over a shared-media network |
| US6223028B1 (en) * | 1997-03-17 | 2001-04-24 | Nortel Networks Ltd | Enhanced method and system for programming a mobile telephone over the air within a mobile telephone communication network |
| US6137791A (en) * | 1997-03-25 | 2000-10-24 | Ericsson Telefon Ab L M | Communicating packet data with a mobile station roaming within an incompatible mobile network |
| US5914950A (en) * | 1997-04-08 | 1999-06-22 | Qualcomm Incorporated | Method and apparatus for reverse link rate scheduling |
| US5940390A (en) * | 1997-04-10 | 1999-08-17 | Cisco Technology, Inc. | Mechanism for conveying data prioritization information among heterogeneous nodes of a computer network |
| US6339595B1 (en) * | 1997-12-23 | 2002-01-15 | Cisco Technology, Inc. | Peer-model support for virtual private networks with potentially overlapping addresses |
| US6223222B1 (en) * | 1998-05-14 | 2001-04-24 | 3Com Corporation | Method and system for providing quality-of-service in a data-over-cable system using configuration protocol messaging |
| US6154778A (en) * | 1998-05-19 | 2000-11-28 | Hewlett-Packard Company | Utility-based multi-category quality-of-service negotiation in distributed systems |
| US6167028A (en) * | 1998-06-01 | 2000-12-26 | Motorola, Inc. | Methods and apparatus for facilitating transmission of cells having multiple priorities in a cell relay network |
| US6157955A (en) * | 1998-06-15 | 2000-12-05 | Intel Corporation | Packet processing system including a policy engine having a classification unit |
| US6094437A (en) * | 1998-10-09 | 2000-07-25 | Asc - Advanced Switching Communications | Layer two tunneling protocol (L2TP) merging and management |
-
1999
- 1999-04-02 US US09/285,817 patent/US6654808B1/en not_active Expired - Lifetime
-
2000
- 2000-03-16 CA CA002300758A patent/CA2300758C/en not_active Expired - Fee Related
- 2000-03-22 EP EP00302358A patent/EP1041792B8/en not_active Expired - Lifetime
- 2000-03-22 DE DE60045355T patent/DE60045355D1/en not_active Expired - Lifetime
- 2000-03-22 AT AT00302358T patent/ATE492095T1/en not_active IP Right Cessation
- 2000-04-03 JP JP2000101549A patent/JP3737668B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| EP1041792A2 (en) | 2000-10-04 |
| US6654808B1 (en) | 2003-11-25 |
| ATE492095T1 (en) | 2011-01-15 |
| JP3737668B2 (en) | 2006-01-18 |
| DE60045355D1 (en) | 2011-01-27 |
| EP1041792B8 (en) | 2011-02-16 |
| JP2000312228A (en) | 2000-11-07 |
| CA2300758A1 (en) | 2000-10-02 |
| EP1041792B1 (en) | 2010-12-15 |
| EP1041792A3 (en) | 2004-07-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2300758C (en) | Providing quality of service in layer two tunneling protocol networks | |
| US7225259B2 (en) | Service tunnel over a connectionless network | |
| US7649890B2 (en) | Packet forwarding apparatus and communication bandwidth control method | |
| US7277455B2 (en) | Packet flow processing in a communication system | |
| US7701963B2 (en) | Method and apparatus for the use of micro-tunnels in a communications system | |
| US8514773B2 (en) | Packet flow processing in a communication system | |
| US6917600B1 (en) | Mobile point-to-point protocol | |
| FI105969B (en) | Quality of service management in a mobile communication system | |
| US6819652B1 (en) | Method and apparatus for processing control messages in a communications system | |
| US20070110060A1 (en) | Packet switching apparatus | |
| EP1371238A2 (en) | Method and apparatus for communicating data based on a plurality of traffic classes | |
| Guo et al. | Providing end-to-end QoS for multimedia applications in 3G wireless networks | |
| McCann et al. | An Internet infrastructure for cellular CDMA networks using mobile IP | |
| EP1043869A2 (en) | Providing quality of service in layer two tunneling protocol networks | |
| Chuah et al. | Mobile virtual private dial‐up services | |
| Sharma et al. | Quality of service guarantee on 802.11 networks | |
| Manner | Provision of Quality of Service in IP-based Mobile Access Networks | |
| Bhagavathula et al. | Mobility and layer 2 tunnels | |
| JP2005535261A (en) | Differentiated management of non-UMTS traffic in UMTS access networks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |