One document matched: draft-zhang-multimob-msm-03.txt
Differences from draft-zhang-multimob-msm-02.txt
MULTIMOB Working Group Hong-Ke Zhang
Internet Draft Zhi-Wei Yan
Expires: January 2012 Shuai Gao
Li-Li Wang
Beijing Jiaotong University
Qian Wu
He-Wu Li
Tsinghua University
July 22, 2011
Multicast Source Mobility Support in PMIPv6 Network
draft-zhang-multimob-msm-03.txt
Abstract
Proxy Mobile IPv6 (PMIPv6), specified in RFC 5213 [1], is a network-
based mobility management protocol. It uses a Mobile Access Gateway
(MAG) and a Local Mobility Anchor (LMA) to allow hosts to move around
within a domain while keeping their address or address prefix stable.
Although the issues of mobile multicast in the PMIPv6 network are
being discussed in the Multimob WG, how to provide the service
connectivity when the multicast source is moving is still a problem
for the PMIPv6. This document proposes and analyzes the potential
solutions of the multicast source mobility in PMIPv6.
Requirements Language
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].
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
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".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
Zhang et al. Expires January, 2012 [Page 1]
Internet-Draft MSM Support in PMIPv6 Network July 2011
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January, 2012.
Copyright Notice
Copyright (c) 2010 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.
Table of Contents
1. Introduction.................................................3
2. Problem statement............................................3
3. Multicast source mobility scheme in PMIPv6...................4
3.1. Data transmission through tunneling.....................4
3.2. Data transmission after tunneling.......................8
4. Extensions of PMIPv6.........................................9
4.1. MAG....................................................10
4.2. LMA....................................................10
5. Format of signaling messages................................10
5.1. PBU....................................................10
5.2. PBA....................................................11
5.3. Multicast address option...............................11
6. Security Considerations.....................................12
7. References..................................................12
Authors' Addresses.............................................14
Acknowledgment.................................................14
Zhang et al. Expires January, 2012 [Page 2]
Internet-Draft MSM Support in PMIPv6 Network July 2011
1. Introduction
Different from Mobile IPv6 (MIPv6) [2], PMIPv6 was proposed to
support the network-based mobility management. The entities in the
PMIPv6 have the responsibilities to track the Mobile Node (MN),
update the location of the MN and redirect the packets to and from
the MN. However, the basic PMIPv6 protocol only solves the mobility
management for the MN which is involved in the unicast communication.
In order to deploy the multicast service in the PMIPv6 network, many
schemes have been proposed [3-6]. However, all of these schemes aim
to support the multicast service for the mobile receiver. How to
support the multicast source mobility in the PMIPv6 network is a
newly planned work in the Multimob WG. Without doubt, the multicast
source mobility is also a very important issue for the deployment of
the multicast service. For example, there is an advanced concept
based on the Intelligent Transport Systems (ITS) service. In this
concept, all the vehicles on the same route are identified by using a
GPS or a car-navigation system. The vehicles multicast real-time
video information about the transportation through the communication
infrastructure like 3G, WiFi to the other vehicles interested in it.
This advance information is called as 'future vision' [7]. The
multicast source mobility is one of the core supporting schemes to
realize the above functions.
In this document, the potential solutions of the multicast source
mobility in PMIPv6 are proposed and analyzed.
2. Problem statement
In PMIPv6 base solution, the LMA and the MAG are two most important
functional entities. The LMA is the home agent for the MN in a PMIPv6
domain. It is the topological anchor point for the MN's home network
prefix(es) and is the entity that manages the MN's binding state. The
MAG is a function on an access router that manages the mobility-
related signaling for an MN that is attached to its access link. It
is responsible for tracking the MN's movements to and from the access
link and for signaling the MN's LMA. Therefore, the topological
location of the MN is not equal to the actual location in the PMIPv6
networks, which brings some problems for the multicast packet
transmission.
And according to the statements in the Section 6.10.5 in RFC5213,
when the MAG receives a packet from an MN connected to its access
link, to a destination that is not directly connected, the packet
MUST be forwarded to the LMA through the bi-directional tunnel
established between the MAG and the MN's LMA. And in Section 6.3 in
RFC5213 it is assumed that the link between the MN and the MAG have
Zhang et al. Expires January, 2012 [Page 3]
Internet-Draft MSM Support in PMIPv6 Network July 2011
multicast capability. However, there is no related description on the
transmission of the multicast data in RFC5213, that is, there is no
scheme about the multicast data forwarding. Thus, the MAG does not
explicitly support the multicast communication. When the multicast
traffic flows arrive at the MAG, for there is no Multicast Forwarding
Information Base (MFIB) on the MAG, it will not be forwarded or
transmitted through the bi-directional tunnel between the MAG and the
LMA and then these packets would be simply discarded by the MAG.
And even though the multicast packets can be transmitted to the LMA
by some special processing, whether the LMA could carry out the
functionality of the Designated Router (DR) can not be guaranteed.
That is, whether the LMA can execute the source registration to the
Rendezvous Point (RP) in the Any Source Multicast (ASM) scenario is
not sure. And similarly in the Source-Specific Multicast (SSM) case,
whether the LMA could forward the packets received from the tunnel
interface to the other multicast router according to the related MFIB
is also not sure. It is possibly because that the LMA is not directly
connected to the source and the network prefix of the LMA's interface
address is different from the Home Network Prefix (HNP) of the MN.
In Section 3, the above mentioned problems of multicast source
mobility in PMIPv6 will be discussed and also some possible solutions
are proposed.
3. Multicast source mobility scheme in PMIPv6
In this section, according to the problem statement in Section 2 and
the path of the multicast packet transmission, it is divided into two
parts to describe the scheme of the multicast source mobility in
PMIPv6.
3.1. Data transmission through tunneling
Because the MAG does not explicitly support the multicast
communication, in order to make the multicast data be forwarded or
transmitted through the bi-directional tunnel between the MAG and the
LMA based on the PMIPv6 protocol, two possible solutions for that are
given as follows.
Solution I: some extensions on the PMIPv6 are required for the
transmission of the multicast data. By establishing multicast
forwarding states on the MAG based on the PMIPv6, the multicast data
sent by the mobile source can be forwarded through the LMA-MAG tunnel
to the LMA after receiving this packet on the MAG. That is, after the
MAG builds the PMIPv6 tunnel and adds route for the anycast packets
originated from or destined to the MN, it should also update the
Zhang et al. Expires January, 2012 [Page 4]
Internet-Draft MSM Support in PMIPv6 Network July 2011
Multicast Forwarding Cache (MFC) for the multicast traffic. Figure 1
shows the detailed procedure of this solution.
+-----+ +-----+ +-----+
| MN | | MAG | | LMA |
+-----+ +-----+ +-----+
| | |
1) |--- Rtr Sol-------->| |
| |------- PBU ----->|
2) | (Multicast address option)
| | |
| | Accept PBU
| | (Allocate HNP,
| | setup BCE and Tunnel)
| |<------ PBA ------|
| | (HNP, Group) |
3) | Accept PBA |
| (Set Up Tunnel |
| and Routing, Update MFC) |
|<---- Rtr Adv ------| |
| | |
4) |-- Multicast Data-->|=Multicast Data==>|
| | |
Figure 1: Procedure of extending the PMIPv6
The detailed descriptions are as follows:
1) The MN connects to the MAG initially and sends Router
Solicitation (RS) message to the MAG;
2) When the attachment of MN is detected by the MAG, it obtains the
group address as well as LMAA and MN_ID from the profile. Then an
extended Proxy Binding Update (PBU) message is sent to the LMA.
Because the LMA finds the Multicast address option contained in
the PBU message, the LMA decide whether the MN is authorized to
send multicast data to the group address. And then the LMA sends
back an extended Proxy Binding Acknowledgement (PBA) message to
the MAG. Afterwards, the tunnel is established in the LMA;
3) The MAG on receiving the PBA message sets up its endpoint of the
bi-directional tunnel to the LMA and then sets up the forwarding
for the MN's unicast traffic. At the same time, in order to
support multicast source mobility, the MAG should also update the
MFC in the kernel. And then it sends Router Advertisement (RA)
Zhang et al. Expires January, 2012 [Page 5]
Internet-Draft MSM Support in PMIPv6 Network July 2011
message to the MN on the access link advertising the MN's HNP as
the hosted on-link prefix;
4) The same as the specification in RFC5213, when the MAG receives a
multicast packet from an MN connected to its access link, to a
multicast destination that has been authorized by the LMA, the
MAG will forward this packet to the LMA through the bi-
directional tunnel established between itself and the LMA.
And the format of the tunnel multicast packets is shown below.
IPv6 header (src= Proxy-CoA, dst= LMAA) /*Tunnel Header*/
IPv6 header (src= MN-HoA, dst= GRPA) /*Packet Header*/
Upper layer protocols /*Packet Content*/
Solution II: some extra functions, such as MLD Proxy as discussed in
RFC 4605 [8] and [draft-schmidt-multimob-pmipv6-base-source] [9],
could be used to transmit the multicast data through the tunnel of
the PMIPv6. The MLD proxy functions are deployed at the MAG as
described in RFC 6224 [10] and the MLD proxy instance serving a
mobile multicast source configures its upstream interface at the
tunnel towards the MN's corresponding LMA. For each LMA, there will
be a separate instance of an MLD proxy.
Although multicast communication can be enabled in PMIPv6 domains by
deploying MLD Proxy functions at MAG, some disadvantages still exist.
Firstly, for a proxy device performing IGMP/MLD-based forwarding has
a single upstream interface and one or more downstream interfaces as
described in RFC4605, there should be many MLD Proxy functions
deployed at one MAG, which is complicated and then is difficult for
implementation and management. And then when the multicast packets
arrive at the MAG running multiple parallel MLD proxy functions,
there may be confusions for the data if there is no extra processing
or filtering scheme at the MAG. In addition, the route optimization
issue is still up in the air, that is, for a mobile receiver and a
source on the same MAG using different LMAs, the traffic has to go up
to one LMA, cross over to the other LMA, and then be tunneled back to
the same MAG, causing redundant flows in the access network and at
the MAG.
Therefore, the MLD Proxy function should be extended to accommodate
the PMIPv6 protocol. As same as the document [9] and [10], the MLD
proxy functions are deployed at the MAG, while only one MLD Proxy
function is required to run at the MAG and multiple upstream
interfaces can be set for the MLD Proxy instance, which is called
Multi-Upstream Interfaces MLD Proxy (MUIMP). Figure 2 shows the
Zhang et al. Expires January, 2012 [Page 6]
Internet-Draft MSM Support in PMIPv6 Network July 2011
architecture of the MUIMP deploying in PMIPv6 for the multicast
source mobility. As shown in Figure 2, the paths among the MAGs and
the LMA represented by "||", "|o|" and "/*/" indicate the tunnels in
base PMIPv6 for the MN1, MN2, and MNn, respectively. In this way,
when the multicast data sent by the mobile source gets to the MAG
from the downstream interface of an MLD proxy, the MAG forwards this
data to the corresponding upstream interface according to the Binding
Update List Entry (BULE) for example at this MAG and to all but the
incoming downstream interfaces with appropriate forwarding states for
this group. And the specific scheme for the choice of the
corresponding upstream interface is outside of this document.
Therefore, multicast packets originating from an MN/mobile source
will arrive at the corresponding LMA and directly at all mobile
receivers co-located at the same MAG. Figure 3 shows the signaling
call flow of the MN attachment in this scheme. And when the MN leaves,
after the deregistration of the PMIPv6 for MNs, the MUIMP deletes the
corresponding upstream tunnel interface for each MN which leaves.
When the MN hands over, it is the same course as the MN attached. And
this scheme can not only solve the route optimization issue as
mentioned in the document [9], but also can be easily to deploy,
implement and manage.
+-------------+
| Content |
| Source |
+-------------+
|
** ** ** **
** ** ** **
** Fixed Internet **
** ** ** **
** ** ** **
/ | \
+----+ +----+ +----+
|LMA1| |LMA2| ... |LMAn| Multicast Anchor
+----+ +----+ +----+
| | |
\\ |o| /*/
\\ |o| /*/
\\ |o| /*/
\\ |o| /*/
\\ |o| /*/ Unicast Tunnel
|
+------------+
Zhang et al. Expires January, 2012 [Page 7]
Internet-Draft MSM Support in PMIPv6 Network July 2011
| MAG | MLD Proxy with multi-upstream interfaces
+------------+
/ | \
{MN1} {MN2}...{MNn}
Figure 2: Architecture of the MUIMP deploying in PMIPv6
MN1 MN2 MAG(MUIMP) LMA1 LMA2
| | | | |
MN1 Attached | | | |
| | | | |
| MN2 Attached | | |
| | | | |
|After configuration of PMIPv6 for | | |
|MNs, the MUIMP adds the corresponding| | |
|tunnel interface as a new upstream | | |
|interface for each MN | | |
| | | | |
|----------- Multicast Data --------->| | |
| | | | |
| | |=Mcast Data=>| |
| | | | |
| |-- Mcast Data -->| | |
| | | | |
| | |========Mcast Data=======>|
| | | | |
Figure 3: Mobile Node Attachment (MUIMP) - Signaling Call Flow
3.2. Data transmission after tunneling
After the processing in Section 3.1, the multicast data arrives at
the LMA through the PMIPv6 tunnel and the subsequent data
transmission is illustrated in detail as follows.
When the LMA can conduct the DR function, the data transmission
procedures are described as follows.
In the scenario of ASM, the multicast receivers send the (*,G) join
message to the RP to establish the RPT from the RP to the receivers.
In this case, the LMA allows a mobile source to continuously send
data to the group through the LMA-MAG tunnel firstly. And then the
packets are transmitted from the LMA to the RP through the source
Zhang et al. Expires January, 2012 [Page 8]
Internet-Draft MSM Support in PMIPv6 Network July 2011
registration and then delivered to the receivers according to the
multicast routing protocols. When the MN hands over from one MAG to
another, only the PMIPv6 tunnel is updated and the movement of source
is transparent to the receivers.
When the data traffic of the multicast source exceeds a certain value
of data rate, the RP sends a (HoA,G) 'connection' message to the
DR/LMA to establish the SPT from the specific source to the RP. Then
the LMA parses this message and establishes the related multicast
state. And when the handover from the Rendezvous Point Tree (RPT) to
the Shortest Path Tree (SPT) happens, the receivers send the join
message (HoA,G) to join the SPT of the source, and then the LMA
receives this message and establishes the related multicast state. In
this way, the LMA-based SPT is established successfully and the
subsequent multicast data flow will be transmitted through the LMA-
based SPT. However, the path between the LMA and the MN is still used
for the multicast packets transmission. Although the SPT handover
finishes, the practical path is not the topological shortest path
tree due to the existence of the PMIPv6 tunnel.
In the SSM case, the multicast receivers actively send the (HoA,G)
subscribe message, for the LMA is just the topological anchor point
of the source's Home Address (HoA) in the PMIPv6 network, this
message is delivered to the LMA firstly and then the LMA-based
multicast SPT from the LMA to the receivers can be established.
Accordingly, the SSM scenario with the LMA-based scheme is similar to
the SPT handover in the ASM scenario with the LMA-based scheme. And
the current SPT path is also not the topological shortest path tree
due to the existence of PMIPv6 tunnel.
As described in RFC 4601 [11], on receipt of data from S to G on
interface iif (incoming interface of the packet), the DR will firstly
check whether the source is directly connected and also the iif is
identical to the Reverse Path Forwarding (RPF) interface. However,
because the network prefix of the LMA's interfaces is not same with
the HNP allocated to the mobile source, the check of the source's
direct connection will not be successful and then the LMA may not
perform the function of the DR for the source. And when the LMA can
not conduct the DR function, some extensions on the LMA should be
needed, which will be our future work for the multicast source
mobility in PMIPv6.
4. Extensions of PMIPv6
The signaling messages and the related processing of basic PMIPv6
should be extended in order to notify the multicast source-related
information from the MAG to the LMA.
Zhang et al. Expires January, 2012 [Page 9]
Internet-Draft MSM Support in PMIPv6 Network July 2011
4.1. MAG
In order to provide the multicast service during the MN's movement,
the MAG must recognize that the attached MN is a multicast source and
the corresponding multicast address must also be learned. These
information can be learned by the MAG during the authentication phase
for example. The particular procedure is out of this document.
When the MAG finds that the attached MN is a multicast source, it
should send the extended PBU message to the LMA. In the extended PBU
message, a one bit "S" flag is added and set to "1", which means the
MN is a multicast source. The multicast address is contained in the
Multicast address option when the "S" is set to "1".
4.2. LMA
When receiving the extended PBU message and finding the "S" flag is
set to "1", the LMA should send back an extended PBA message with the
"S" flag set to "1" to the MAG. And then the LMA establishes a tunnel
to the MAG as specified in PMIPv6.
5. Format of signaling messages
5.1. PBU
The format of the PBU message is shown in Figure 4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|S| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast address option .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: PBU Message Format
S flag and Multicast address option
Zhang et al. Expires January, 2012 [Page 10]
Internet-Draft MSM Support in PMIPv6 Network July 2011
1-bit "Multicast source identification" flag is used to identify
whether this MN is a mobile multicast source. When this flag is set
to "1", the related multicast address is attached in the Multicast
address option.
5.2. PBA
The format of the PBA message is shown in Figure 5.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|S| Res. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast address option .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: PBA Message Format
S flag and Multicast address option
1-bit "Multicast source identification" flag is used to identify
whether this MN is a mobile multicast source. The flag is set to "1"
only if the corresponding PBU had the S flag set to "1". And when
this flag is set to "1", the related multicast address is attached in
the Multicast address option.
5.3. Multicast address option
The format of Multicast address option is illustrated in Figure 6.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast address +
| |
Zhang et al. Expires January, 2012 [Page 11]
Internet-Draft MSM Support in PMIPv6 Network July 2011
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Multicast Address Option
Option Type
TBD
Option Length
8-bit unsigned integer indicating the length of the option in octets,
excluding the option type and option length fields. This field can be
set to 16 and 4 for the IPv6 and IPv4 multicast addresses,
respectively.
Multicast address
The multicast address related to the multicast session provided by
the MN.
6. Security Considerations
This document does not introduce any security considerations.
7. References
[1] Gundavelli, et al.. "Proxy Mobile Ipv6", RFC5213, August 2008.
[2] David B. Johnson, Charles E. Perkins and Jari Arkko. "Mobility
Support in IPv6", RFC 3775, June 2004.
[3] T C. Schmidt, M. Waehlisch and S. Krishnan. "Base Deployment
for Multicast Listener Support in PMIPv6 Domains", draft-ietf-
multimob-pmipv6-base-solution-07, December 29, 2010.
[4] H. Asaeda, P. Seite and J. Xia. "PMIPv6 Extensions for
Multicast", draft-asaeda-multimob-pmip6-extension-04, September
9, 2010.
[5] Seil Jeon and Younghan Kim. "Mobile Multicasting Support in
Proxy Mobile IPv6", draft-sijeon-multimob-mms-pmip6-02, March 4,
2010.
Zhang et al. Expires January, 2012 [Page 12]
Internet-Draft MSM Support in PMIPv6 Network July 2011
[6] T C. Schmidt, M. Waehlisch, R. Koodli and G. Fairhurst.
"Multicast Listener Extensions for MIPv6 and PMIPv6 Fast
Handovers", draft-schmidt-multimob-fmipv6-pfmipv6-multicast-03,
November 08, 2010.
[7] K. Sato, M. Katsumoto, T. Miki. "Future vision distribution
system and network", This paper appears in: IEEE International
Symposium on Communications and Information Technology, 2004.
ISCIT 2004, vol.1, pp: 274 - 279, October 2004.
[8] B. Fenner, H. He, B. Haberman and H. Sandick. "Internet Group
Management Protocol (IGMP) / Multicast Listener Discovery
(MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC
4605, August 2006.
[9] T C. Schmidt, M. Waehlisch and M. Farooq. "Mobile Multicast
Sender Support in PMIPv6 Domains with Base Multicast
Deployment", draft-schmidt-multimob-pmipv6-base-source-00,
March 28, 2011.
[10] T. Schmidt, M. Waehlisch and S. Krishnan. "Base Deployment for
Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6)
Domains", RFC 6224, April 2011.
[11] B. Fenner, M. Handley, H. Holbrook and I. Kouvelas. "Protocol
Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", RFC 4601, August 2006.
Zhang et al. Expires January, 2012 [Page 13]
Internet-Draft MSM Support in PMIPv6 Network July 2011
Authors' Addresses
Hong-Ke Zhang, Zhi-Wei Yan, Shuai-Gao, Li-Li Wang
National Engineering Lab for NGI Interconnection Devices
Beijing Jiaotong University, China
Phone: +861051684274
Email:hkzhang@bjtu.edu.cn
06120232@bjtu.edu.cn
shgao@bjtu.edu.cn
liliwang@bjtu.edu.cn
Qian Wu, He-Wu Li
Network Research Center
Tsinghua University, China
Phone: +861062772375
Email:wuqian@cernet.edu.cn
lihewu@cernet.edu.cn
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zhang et al. Expires January, 2012 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 16:00:38 |