Internet DRAFT - draft-zhang-tsvwg-tunnel-congestion-exposure
draft-zhang-tsvwg-tunnel-congestion-exposure
TSVWG L. Zhu
Internet-Draft Huawei Technologies
Intended status: Informational H. Zhang
Expires: April 18, 2013 X. Gong
BUPT
October 15, 2012
Tunnel Congestion Exposure
draft-zhang-tsvwg-tunnel-congestion-exposure-00
Abstract
At present, tunneling technology has been widely applied in VPN,
mobile communication network, IPv6 over IPv4, Mobile IP, multi-point
delivery, and other fields. In the E2E link, there may already have
been an effective congestion control mechanism, but we SHOULD also do
traffic management in the tunnel to improve the performance of the
entire network. Because of the particularity of the scenario of the
tunnel, the existing E2E traffic management mechanism cannot be
directly be deployed (e.g. VPN, IPv6 over IPv4 etc). In these
cases, this document focuses on how to expose the congestion while
the feedback mechanism is left for later study. This document
describes the problem of identifying congestion in a tunnel segment
of an end-to-end flow. A basic tunnel congestion exposure model is
then described, followed by three example scenarios which use the
basic model to derive tunnel congestion. Finally, a general solution
that can be applied to IP-in-IP tunnels is described.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2013.
Copyright Notice
Zhu, et al. Expires April 18, 2013 [Page 1]
Internet-Draft Tunnel Congestion Exposure October 2012
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Zhu, et al. Expires April 18, 2013 [Page 2]
Internet-Draft Tunnel Congestion Exposure October 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Document Overview . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
4. Basic Model . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 10
5.1. VPN Scenario . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Mobile Scenario . . . . . . . . . . . . . . . . . . . . . 11
5.3. IPv6 over IPv4 Scenario . . . . . . . . . . . . . . . . . 12
6. The General Solution . . . . . . . . . . . . . . . . . . . . . 13
6.1. Statement of Requirements . . . . . . . . . . . . . . . . 13
6.2. The General Procedure . . . . . . . . . . . . . . . . . . 14
7. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative Reference . . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Zhu, et al. Expires April 18, 2013 [Page 3]
Internet-Draft Tunnel Congestion Exposure October 2012
1. Introduction
This document mainly describes four issues.
Firstly, this document describes the problem concerning congestion in
the tunnel. At present, tunneling technology has been widely applied
in, VPN, mobile communication network, IPv6 over IPv4, Mobile IP,
multi-point delivery, and other fields. In this case, relying on
end-to-end congestion management alone to deal with the congestion
problem in the tunnel brings many drawbacks and seriously affects the
performance of the entire network.
Secondly, this document proposes a basic tunnel congestion exposure
model. In the model, the ingress and the egress of the tunnel are
two dominant nodes which have the ability to handle admission, flow
control and policy control.
In the basic model, in order to achieve a real-time understanding of
the congestion status of the tunnel, the amount of tunnel congestions
is fed back to the ingress of the tunnel using the tunnel
encapsulation protocol signals. It's helpful for the ingress to
achieve a real-time congestion status of the entire tunnel, and it
also provides the possibility of using policy or flow control
mechanisms to further reduce congestion in the local tunnel portion.
Thirdly, this document introduces three example scenarios where the
proposed basic model can be applied.
Finally, this document presents a general solution. The general
solution includes a statement of requirements and general procedures.
1.1. Document Overview
The main section in this document is the basic model described in
chapter 4. A tunnel congestion exposure model is presented in the
chapter. The model is relatively simple, but it can be used to
sufficiently expose the tunnel congestion. Chapter 3 gives the
general process of tunnel transmission and presents two major
problems related to the tunnel congestion. Three scenarios are given
in Chapter 5 that use the basic model. Chapter 6 introduces a
general solution. Chapter 7 states a further study plan.
2. Conventions and Terminology
Zhu, et al. Expires April 18, 2013 [Page 4]
Internet-Draft Tunnel Congestion Exposure October 2012
2.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119].
Table 1 recaps the names of the ECN codepoints [RFC3168].
+------------------+----------------+---------------------------+
| Binary codepoint | Codepoint name | Meaning |
+------------------+----------------+---------------------------+
| 00 | Not-ECT | Not ECN-capable transport |
| 01 | ECT(1) | ECN-capable transport |
| 10 | ECT(0) | ECN-capable transport |
| 11 | CE | Congestion experienced |
+------------------+----------------+---------------------------+
Table 1: Recap of Codepoints of the ECN Field [RFC3168]
2.2. Terminology
Further terminology used within this document:
o Tunnel: A tunnel is just a special type of connection across a
network.
o Encapsulation: The process of adding control information as it
passes through the layered model.
o Encapsulator: The tunnel endpoint function that adds an outer IP
header to tunnel a packet, the encapsulator is considered as the
"ingress" of the tunnel.
o Decapsulator: The tunnel endpoint function that removes an outer
IP header from a tunnelled packet, the decapsulator is considered
as the "egress" of the tunnel.
o Outer header: The header added to encapsulate a tunneled packet.
o Inner header: The header encapsulated by the outer header.
o E2E: End to End
o VPN: Virtual Private Network is a technology for using the
Internet or another intermediate network to connect computers to
isolated remote computer networks that would otherwise be
inaccessible.
Zhu, et al. Expires April 18, 2013 [Page 5]
Internet-Draft Tunnel Congestion Exposure October 2012
3. Problem Statement
Tunneling technology is one way to transmit data between different
networks by using the Internet infrastructure. The tunnel can
transmit the frames or packets of different protocols as its payload.
The frames or packets are re-encapsulated using new headers of the
tunneling protocol. The new header provides the routing information
so that the encapsulated payload data can be transmitted through the
public Internet. As soon as being transmitted to the endpoint of
network (egress), the data will be de-encapsulated and forwarded to
its final destination.
In the IP network, there are three typical encapsulation protocols:
IP Encapsulation within IP [RFC2003]; Minimal Encapsulation within IP
[RFC2004]; Generic Routing Encapsulation (GRE) [RFC1701].
As an example, the format of GRE encapsulation is shown in Figure 1.
+------------------------+
| IP |
| (payload Protocol) |
+------------------------+
| GRE |
|(Encapsulation Protocol)|
+------------------------+
| IP |
| (Transport Protocol) |
+------------------------+
Figure 1: GRE encapsulation format
At present, tunneling technology is widely used in computer networks.
It MAY be used to transport IPv4 in IPv6 networks and vice versa
during the two protocols coexistence period. In Mobile IP, by
introducing tunnels, a mobile node can communicate with its
correspondent node using a fixed address (home address) at any time
and place. In addition, tunneling technology has also played an
important role in virtual private network (VPN), multi-point
delivery, and mobile communication networks.
We perceive two problems related to congestion and tunneling
technology in IP and mobile communication networks.
Consider the following situation: data packets need to be transmitted
end-to-end over an ECN-enabled transport and part of this includes a
tunnel segment.
Zhu, et al. Expires April 18, 2013 [Page 6]
Internet-Draft Tunnel Congestion Exposure October 2012
The ingress, the egress and the intermediate nodes of the tunnel are
ECN-enabled. At the egress of the tunnel, the data packets are de-
capsulated, peeled off the transport protocol in outer header, and
then the inner packets are forwarded to the destination endpoint.
In this case, it is useful to specify the behaviors of the
encapsulation and de-capsulation; otherwise the following problems
may occur:
o The packet congestion inside the tunnel cannot be indicated;
o E2E path congestion information may be lost.
For these two problems, RFC3168, RFC4301 and RFC6040 have presented
some descriptions and specifications to all IP in IP tunnels.
The core idea is:
o Set the ECN bits as ECT(0)/ECT(1) at the ingress in order to
inform the interior router to perform mark operations and indicate
congestion events inside the tunnel;
o Perform "copy-to-copy" operations at the ingress and egress of the
tunnel, so that the congestion information of the arriving packet
or inside the tunnel can be forwarded to the final endpoint
instead of being lost.
In the mobile communication network, end-user IP traffic maybe
forwarded over multiple tunnel segments before it reaches the router
that handles subscriber policy, charging etc. Congestion over these
tunnel segments contribute to the overall congestion experienced E2E.
In the tunnel protocol deployment scenarios, we may use other
methods, for example, out of-band signaling, to report the congestion
information to NE (Network Element) which has the mechanisms to
manage congestion based on per user policies or other flow control
mechanisms.
However, tunnel congestion information should not be overlooked. In
the E2E link, there may already have been an effective congestion
control mechanism, but we SHOULD also do traffic management in the
tunnel to improve the performance of the entire network. Because of
the particularity of the scenario of the tunnel, the existing E2E
traffic management mechanism cannot be directly be deployed (e.g.
VPN, IPv6 over IPv4 etc). In these cases, this document focuses on
how to expose the congestion while the feedback mechanism is left for
later study.
Zhu, et al. Expires April 18, 2013 [Page 7]
Internet-Draft Tunnel Congestion Exposure October 2012
The following assumptions are made in this document:
o Firstly, both payload and transport protocols are IP in this
document, i.e., we consider only IP-in-IP tunnels;
o Secondly, the intermediate nodes within the tunnels, for example,
the routers are ECN-enabled;
o Finally, no changes are made to the ECN mechanism.
4. Basic Model
According to the general tunnel transmission process, this section
introduces the abstract of the tunnel transmission and outlines a
tunnel congestion exposure model as shown in Figure 2:
,-----------. TUNNEL ,-----------.
| Ingress |==========================================| Egress |
| | | |
| ,---------------Congestion-Indication------------------. |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | ,-----------. '\ | | |
| | |____________| |____________| \ | | |
| | | Outer Header(IP Layer) Data Flow \ |+----+----+|
|+----v----+| | | \||Feedback ||
||Collector|| |(Congested)| /|+---------+|
|+---------+| | Router |--Outer-CE-Signals--> Meter ||
| |____________| |____________ / |+---------+|
| | | | |/ | |
| | `-----------' ' | |
| |==========================================| |
`-----------' `-----------'
Figure 2: Tunnel Congestion Exposure Basic Model
This basic model MAY contain the following components: Ingress,
Egress, Collector, Feedback and Meter.
By and large, the ingress and egress of the tunnel are gateway
devices. In terms of the egress, it can calculate the amount of
congestion and feed back the congestion information to the ingress.
The collector is able to receive the congestion information which is
Zhu, et al. Expires April 18, 2013 [Page 8]
Internet-Draft Tunnel Congestion Exposure October 2012
fed back from the egress. It MAY also have admission control and
flow control functions.
General practice can be as follows:
At the egress, a module named meter can be added. The module records
the outer header CE codepoint packets reaches the egress
independently, and MAY need to estimate the congestion level inside
the tunnel. In addition, a congestion information feedback module,
called feedback, is also needed to be added. The feedback module is
used to control the congestion information feedback. The feedback of
the congestion information can be done via the extension of the
encapsulation protocol of the tunnel.
A collector module for receiving the feedback congestion information
from the egress SHOULD be added. The collector can be distributed in
the ingress or other network elements that have the capability of
handling the congestion (such as the PDN-GW in the mobile
communication network described in section 5.2). Furthermore, some
modules related with the congestion policy process can be added.
However, no descriptions concerning this aspect are given in this
document for the time being.
In this model, the tunnel is an IP-in-IP tunnel. Both the entry and
egress of the tunnel are ECN-enabled and the intermediate routers in
the tunnel path are also ECN-enabled.
+---------------+ +-------------+
| Ingress | | Egress |
+-------+-------+ +------+------+
| |
| Record the congestion
| |
| |
|<-------------Send Back Congestion---------------+
| |
| |
Settle the congestion |
| |
Figure 3: the general process of the congestion feedback
Figure 3 demonstrates the general process of the congestion
information feedback.
The general method to feed back the congestion information is to do
Zhu, et al. Expires April 18, 2013 [Page 9]
Internet-Draft Tunnel Congestion Exposure October 2012
some extensions to the encapsulation protocol messages. The details
of the feedback process may differ in terms of the encapsulation
protocols of the tunnel, but the general process is as shown in
Figure 3.
5. Example Scenarios
This chapter presents three scenarios based on the basic model
described in the previous chapter. This chapter focuses on two
aspects. On the one hand, it describes the process of tunnel
congestion exposure for each scenario, and on the other hand it
stresses the significance of congestion exposure.
5.1. VPN Scenario
.---. .---.
( ) ( )
/ \ / \
( VPN 1 ) ( VPN 1 )
\ +--+ +--+ /
( |CE| |CE| )
.--+--+ +--+--.
\ /
\ (--------------------) /
\ ( ) /
+--+ ( ) +--+
|PE|---( IP Network )---|PE|
+--+ ( ) +--+
/| ( ) |\
/ | (--------------------) | \
/ | | \
.--+--+ |===============================| +--+--.
( |CE| | VPN Tunnel | |CE| )
/ +--+ +--+ \
( VPN 2 ) ( VPN 2 )
\ / \ /
( ) ( )
.---. .---.
Figure 4: VPN Scenario
Figure 4 is a simplified VPN multi-instance model. A VPN tunnel is
established between two PEs. Before creating the VPN tunnel, the
routing in the network between two PEs has been configured (e.g., in
large networks, the BGP routing protocol is generally used). CEs are
Zhu, et al. Expires April 18, 2013 [Page 10]
Internet-Draft Tunnel Congestion Exposure October 2012
connected to the networks where the users locate. Both ends of the
CE devices are located respectively in the VPN instance 1 (VPN 1) and
VPN instance 2 (VPN 2).
CE and PE are defined as follows:
o CE (Customer Edge): User network edge devices, which have
interfaces directly to the SP (Service Provider) networks. A CE
can be a switch and can also be a host. Usually, the CE cannot
sense the presence of the VPN and it does not need to support the
VPN features.
o PE (Provider Edge): IP network edge devices, which are connected
to CEs directly. In the VPN network, all processing of VPN
instances is on the PEs.
In this scenario, the VPN Tunnel is the object drawing our attention.
The two PEs are the powerful nodes that acting as the entry and
egress of the tunnel, receiving and sending back the congestion
information. The PEs can also do more operations of the traffic
management. The process is almost the same as that of the basic
model.
5.2. Mobile Scenario
Figure 5 is the scenario in the EPS (Evolved Packet System), where
two PMIP tunnels exist, i.e., PMIP tunnel between eNodeB and the
S-GW, and between the S-GW and the PDN-GW. In this scenario, we can
just expose the congestion information of the backhaul tunnel segment
(Note: It is an assumption that core network has extremely low
possibility of congestion). With the extensive use of mobile
communication network and variable traffic rate per user, backhaul
network congestion problems get more unpredictable. If the
congestion information in the backhaul network can be exposed, the
PDN-GW MAY reuse the exposed congestion information to do flow
control, which is helpful to improve the performance of the entire
network and enhance the user experience.
There are significant differences between this scenario and the VPN
scenario.
o First of all, the congestion information is reported to PDN-GW
rather than the ingress.
o Secondly, no congestion feedback exists in the backhaul network in
both the uplink and downlink.
Zhu, et al. Expires April 18, 2013 [Page 11]
Internet-Draft Tunnel Congestion Exposure October 2012
o In addition, the object which is used to reporting the tunnel
congestion information (PDN-GW) and the module used to record the
congestion information are not in the same tunnel section.
\|/
|
|
+-|------+ +--------+ PMIP +--------+
+--+ | | Tunnel1 | | Tunnel2 | |
|UE|--(RAN)--| eNodeB |===========| S-GW |=============| PDN-GW |
+--+ | | Backhaul | | Core | |
+--------+ +--------+ +--------+
Figure 5: Mobile Scenario
In this scenario, the processing in the uplink and downlink SHOULD be
distinguished. The general process is as follows:
o The egress records the congestion information according to the
description in the basic model.
o In the uplink direction, the egress is S-GW. Therefore, the S-GW
will report congestion information to the PDN-GW using the PMIP
messages.
o In the down-link direction, the egress is the eNodeB. The eNodeB
feeds back the congestion information to the S-GW first using the
PMIP messages. Then the S-GW transfers the congestion information
to the PDN-GW.
5.3. IPv6 over IPv4 Scenario
The tunnel used to connect IPv6 isolated islands in an IPv4 network
is called IPv6 over IPv4 tunnel.
In the early stage of the transition from the IPv4 Internet to the
IPv6 Internet, the IPv4 networks have been well deployed while the
IPv6 networks are isolated network islands spread around the world.
Using a dedicated line to connect these isolated IPv6 islands is not
economical obviously. The usual practice is to use tunneling
technology. By using the tunneling technology to create a tunnel in
the IPv4 network, the IPv6 islands can be interconnected through the
IPv4 networks. This is similar to the deployment of VPNs in the IP
networks through the tunneling technology.
Zhu, et al. Expires April 18, 2013 [Page 12]
Internet-Draft Tunnel Congestion Exposure October 2012
.----.
+--------+ ( ) +--------+
| | / IPv4 \ | |
|Gateway1| ( Network ) |Gateway2|
| | TUNNEL \ / | |
+---|----+==============(======)===============+----|---+
| .----. |
| |
| |
| |
| |
.---. .---.
( ) ( )
/ IPv6 \ / IPv6 \
( Network ) ( Network )
\ / \ /
( ) ( )
.---. .---.
Figure 6: IPv6 over IPv4 Scenario
In this scenario, the two gateways, namely Gateway1 and Gateway2,
perform admission control. They are the endpoints of the connection
to the two IPv6 isolated islands and serve as the ingress and egress
of the tunnel. It can be seen from above, the specific congestion
exposure mechanisms are consistent with the basic model.
The congestion information is exposed at the ingress, we can use the
congestion information to do a lot of significant things.
6. The General Solution
6.1. Statement of Requirements
o All tunnels are IP-in-IP type.
o Tunnel path supports the ECN mechanism--that is, the ingress, the
egress and intermediate nodes are ECN enabled.
o The tunnel is configured to support feedback congestion
information.
o A powerful device exists in the tunnel which is used for
processing the congestion information.
Zhu, et al. Expires April 18, 2013 [Page 13]
Internet-Draft Tunnel Congestion Exposure October 2012
6.2. The General Procedure
o In case of congestion, network element (ingress and egress of the
tunnel, intermediate routers etc.) performs marking operations on
packets according to AQM algorithm.
o The egress of the tunnel calculates congestion information by
recording the number of congestion and total package periodically.
o The egress of the tunnel feeds back congestion information to the
functional traffic management entity (such as: the ingress of the
tunnel). In the tunnel, if the transport protocol is UDP, the
congestion information is fed back by extending signaling of the
encapsulation protocol. In this step, the encapsulation signaling
SHOULD be extended. For example, in the IPSec tunnel, the IPSec
signaling messages should be extended which are used for sending
back the congestion information to the collector module.
o Congestion information receiving object (functional entity
executing flow management) disposes congestion information when
the congestion threshold level is reached. Here, we can define
the different congestion levels according to the actual situations
or requirements. For the simplest condition, we can divide the
congestion conditions into three types: the high congestion,
moderate congestion, and low-grade congestion. This process
involves things like collecting congestion information, making
policy control based on the congestion information and etc.
7. Next Steps
At present, this document focuses on how to expose the tunnel
congestion to the ingress of the tunnel which has flow control and
policy control functions etc. In this document, a basic model for
congestion exposure is proposed, a general solution is introduced,
and several scenarios for applying the basic model are described.
However, no excessive details are given.
In the following versions, more details and processes of the tunnel
congestion exposure will be introduced. Which type of congestion
information and how to use the information will also be discussed.
In the near future, more than one document will be used to describe
these practices.
8. Security Considerations
TBD
Zhu, et al. Expires April 18, 2013 [Page 14]
Internet-Draft Tunnel Congestion Exposure October 2012
9. IANA Considerations
This document includes no request to IANA.
10. Acknowledgments
The authors would like to thank Wendong Wang, Li Yuhong and Xirong
Que for their technical guidances towards to this draft.
The authors would like to thank their colleagues for their sincerely
help and comments when drafting this document.
11. References
11.1. Normative Reference
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, November 2010.
11.2. Informative References
[3GPP.23.203]
3GPP, "Policy and charging control architecture", 3GPP TS
23.203 10.7.0 , June 2012.
[3GPP.23.402]
3GPP, "Architecture enhancements for non-3GPP accesses",
3GPP TS 23.402 V11.3.0 , June 2012.
[3GPP.29.274]
3GPP, "Technical Specification Group Core Network and
Terminals; 3GPP Evolved Packet System (EPS); Evolved
General Packet Radio Service (GPRS) Tunneling Protocol for
Control plane (GTPv2-C)", 3GPP TS 29.274 V11.2.0 ,
March 2012.
Zhu, et al. Expires April 18, 2013 [Page 15]
Internet-Draft Tunnel Congestion Exposure October 2012
[I-D.ietf-conex-abstract-mech]
Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
Concepts and Abstract Mechanism",
draft-ietf-conex-abstract-mech-05 (work in progress),
July 2012.
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
Authors' Addresses
Lei Zhu
Huawei Technologies
Huawei Building, Q20 No.156 Beiqing Rd.Z-park
Haidian District, Beijing 100095
P. R. China
Email: lei.zhu@huawei.com
Huabing Zhang
Beijing University of Posts and Telecommunications
Xitucheng road 10
Haidian District, Beijing 100876
P. R. China
Email: zhanghb29@gmail.com
Xiangyang Gong
Beijing University of Posts and Telecommunications
Xitucheng road 10
Haidian District, Beijing 100876
P. R. China
Email: xygong@bupt.edu.cn
Zhu, et al. Expires April 18, 2013 [Page 16]
