[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

Network working group                                    M. Bianchetti
Internet Draft                                             G. Picciano
Intended status: Informational                          Telecom Italia
Expires: January 1, 2010                                       M. Chen
                                                                J. Qiu
                                          Huawei Technologies Co., Ltd.
                                                          July 6, 2009




            Requirements for IP multicast performance monitoring
            draft-bipi-mboned-ip-multicast-pm-requirement-00.txt


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.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 15, 2009.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.




Qiu                   Expires January 1, 2010                [Page 1]


Internet-Draft      IP Multicast PM requirements             July 2009


Abstract

   With increasing deployment of IP multicast in service provider (SP)
   network, SPs need a carrier-grade IP multicast performance monitoring
   solution. This document describes the requirements for such a system
   for a SP network. This system enables efficient performance
   monitoring in SPs' production network and provides diagnostic
   information in case of performance degradation or failure.

Table of Contents


   1. Introduction................................................2
   2. Conventions used in this document............................4
   3. Terminologies...............................................4
   4. Functional Requirements......................................6
      4.1. Topology discovery and monitoring.......................6
      4.2. Performance measurement.................................6
         4.2.1. Loss rate.........................................6
         4.2.2. One-way delay......................................7
         4.2.3. Jitter............................................7
         4.2.4. Throughput.........................................7
      4.3. Measurement session management..........................8
         4.3.1. Segment v.s. Path..................................8
         4.3.2. Static v.s. Dynamic configuration..................8
         4.3.3. Proactive v.s. on-demand...........................9
      4.4. Measurement result report...............................9
         4.4.1. Performance reports................................9
         4.4.2. Exceptional alarms.................................9
   5. Design considerations.......................................10
      5.1. Inline data-plane measurement..........................10
      5.2. Scalability...........................................10
      5.3. Robustness............................................11
      5.4. Security..............................................11
      5.5. Device flexibility.....................................11
      5.6. Extensibility.........................................12
   6. Security Considerations.....................................12
   7. IANA Considerations........................................12
   8. References.................................................12
      8.1. Normative References...................................12
      8.2. Informative References.................................12
   9. Acknowledgments............................................13

1. Introduction

   This document describes the requirement for an IP multicast
   performance monitoring system for service provide (SP) IP multicast


Bianchetti, et al.     Expires January 6, 2010                [Page 2]


Internet-Draft      IP Multicast PM requirements             July 2009


   network. This system enables efficient monitoring of performance
   metrics of any given multicast channel (*,G) or (S,G) and provides
   diagnostic information in case of performance degradation or failure.

   Increasing deployment of IP multicast in SP network calls for a
   carrier-grade IP multicast performance monitoring solution. SPs have
   been leveraging IP multicast to provide revenue-generating services,
   such as IP television (IPTV), video conferencing, as well as the
   distribution of stock quotes or news. These services are usually
   loss-sensitive or delay-sensitive, and their data packets need to be
   delivered over a large IP network in real-time.  Accordingly, these
   services demands very strict service-level agreements (SLAs). For
   example, loss rate over 5% is generally considered unacceptable for
   IPTV delivery. Video conferencing normally demands delays no more
   than 150 milliseconds. However, the real-time nature of the traffic
   and the deployment scale of service make it very challenging for IP
   multicast performance monitoring in a SP's production network. With
   increasing deployment of multicast service in SP networks, it becomes
   mandatory to develop an efficient solution that is designed for SPs
   to solve the following problems.

   o SLA monitoring and verification: verify whether the performance of
      production multicast network meets SLA requirements.

   o Network optimization: identify bottlenecks when the performance
      metrics do not meet the SLA requirements.

   o Fault localization: pin-point impaired components in case of
      performance degradation and service disruption.

   These capabilities ease the management and maintenance costs of IP
   multicast network for SPs, and ensure quality of services.

   However, the existing IP multicast monitoring tools and systems,
   which were mostly designed either for primitive connectivity
   diagnosis or for experimental evaluations, does not suit for a SP
   production network, given the following facts:

   o Most of them provide end-to-end reachability check only [4][6][8].
      They cannot provide sophisticated measurement metrics such as
      packet loss, one-way delay, and jitter, for the purpose of SLAs
      verification.







Bianchetti, et al.     Expires January 6, 2010                [Page 3]


Internet-Draft      IP Multicast PM requirements             July 2009


   o Most of them can perform end-to-end measurements only. For example,
      RTCP-based monitoring system [7] can report end-to-end packet loss
      rate and jitter. End-to-end measurements are usually inadequate
      for fault localization, which needs fine-grain measurement data to
      pin-point exact root causes.

   o Most of them use probing packets to probe network performance [4]
      [6]. The approach might yield biased or even irrelevant results
      because the probing results are sampled and the out-of-band
      probing packets might be forwarded differently from the monitored
      user traffic.

   o Most of them are not scalable in a large deployment like SPs'
      production network. For example, in IPTV deployment, the number of
      group member might be in the order of thousands.  In this scale, a
      RTCP-based multicast monitoring system [7] becomes almost unusable
      because RTCP report intervals of each receiver might be delayed up
      to minutes or even hours because of over-crowded reporting
      multicast channel [14].

   o Some of them rely on the information from external protocols,
      which make their capabilities and deployment scenarios limited by
      the external protocols. The examples are passive measurement tools
      that collect and analyze messages from protocols such as multicast
      routing protocols [9], IGMP [11], or RTCP [7], etc.  Another
      example is a SNMP-based system [10] that collects and analyzes
      relevant multicast MIB information.

   This document specifies the requirements for an IP multicast traffic
   monitor for a carrier-grade IP multicast network, which help SPs to
   do SLA verification, network optimization, and fault localizations in
   a large production network.

2. Conventions used in this document

   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 RFC-2119 [1].

3. Terminologies

   o SSM (source specific multicast): When a multicast group is
      operating in SSM mode, only one designated node is eligible to
      send traffic through the multicast channel. A SSM multicast group
      with the designated source address s and group address G is
      denoted by (s, G).



Bianchetti, et al.     Expires January 6, 2010                [Page 4]


Internet-Draft      IP Multicast PM requirements             July 2009


   o ASM (any source multicast): When a multicast group is operating in
      ASM mode, any node can multicast packets through the multicast
      channel to other group members. An ASM multicast group with group
      address G is denoted by (*, G).

   o Root (of a multicast group): In a SSM multicast group (s, G), the
      root of this group is the first-hop router next to the source node
      s. In an ASM multicast group (*, G), the root of this group is the
      selected rendezvous point router.

   o Receiver: The term receiver refers to any node in the multicast
      group that receives multicast traffic.

   o Internal forwarding path: Given a multicast group and a forwarding
      node in the group, the internal forwarding path inside the node
      refers to the data path between the upstream interface towards the
      root and one of the downstream interface towards the receivers.

   o Multicast forwarding path: Given a multicast group, a multicast
      forwarding path refers to the sequence of the interfaces, links
      and internal forwarding paths from the downstream interface at
      root until the upstream interface at a receiver.

   o Multicast forwarding tree: Given a multicast group G, the union of
      all multicast forwarding paths composes the multicast forwarding
      tree.

   o Segment (of multicast forwarding path): The segment of a multicast
      forwarding path refers to part of the path between any two given
      interfaces.

   o Measurement session: A measurement session refers to the period of
      time in which certain performance metrics over a segment of
      multicast forwarding path is monitored and measured.

   o Monitoring node: A monitoring node is a node on a multicast
      forwarding path that is capable of performing traffic performance
      measurements on its interfaces.

   o Active interface: An interface of a monitoring node that is turned
      on to start a measurement session is said active.

   o Measurement session control packets: The packets are used for
      dynamic configuration for active interface to coordinate
      measurement sessions.




Bianchetti, et al.     Expires January 6, 2010                [Page 5]


Internet-Draft      IP Multicast PM requirements             July 2009


   Figure 1 shows a multicast forwarding tree rooted at a root's
   interface A. Within router 1, B-C and B-D are two internal forwarding
   paths. Path A-B-C-E-G-I is a multicast forwarding path, which starts
   at root's downstream interface A and ends at receiver 2's upstream
   interface I. A-B, B-C-E are two segments of this forwarding path.
   When a measurement session for a metric such as loss rate is turned
   on over segment A-B, interfaces A and B are active interfaces.

   +--------+
   | source |                                             I +--------+
   +---#----+                                          +---<> recv 2 |
       # Unicast                      +----------+ G   |    +--------+
       #           +----------+ C   E |          <>----+
   +---#--+ A    B |          <>-----<> router 2 |
   | root <>------<> router 1 |       |          <>----+
   +------+        |          <>---+  +----------+ H   |  J +--------+
                   +----------+ D  |                   +---<> recv 3 |
                                   | F +--------+           +--------+
                                   +--<> recv 1 |
                                       +--------+
      <> C    Interface
      ------  Link

   Figure 1. Example of multicast forwarding tree

4. Functional Requirements

4.1. Topology discovery and monitoring

   The monitor system SHOULD have mechanisms to collect topology
   information of the multicast forwarding trees for any given multicast
   group. The function can be an integrated part of this monitoring
   system. Alternatively, the function might relies on other tools and
   protocols, such as mtrace [5], MANTRA[9], etc. The topology
   information will be referred by network operators to decide where to
   enable measurement sessions.

4.2. Performance measurement

   The performance metrics that a monitoring node needs to collect
   include but not limit to the following.

4.2.1. Loss rate

   Loss rate over a segment is the ratio of user packets not delivered
   to the total number of user packets delivered over this segment
   during a given interval. The number of user packets not delivered


Bianchetti, et al.     Expires January 6, 2010                [Page 6]


Internet-Draft      IP Multicast PM requirements             July 2009


   over a segment is the difference between the number of packets
   transmitted at the starting interface of the segment and received at
   the ending interface of this segment. Loss rate is crucial for
   multimedia streaming, such as IP, video/audio conferencing.

   Loss rate over any segment of a multicast forwarding path MUST be
   provided. The measurement interval MUST be configurable.

4.2.2. One-way delay

   One-way delay over a segment is the average time that user packets
   take to traverse this segment of forwarding path during a given
   interval. The time that a user packet traversing a segment is the
   difference between the time when the user packet leaves the starting
   interface of this segment and the time when the same user packet
   arrives at the ending interface of this segment. The one-way delay
   metric is essential for real-time interactive applications, such as
   video/audio conferencing, multiplayer gaming.

   One-way delay over any segment of a multicast forwarding path SHOULD
   be able to be measured. The measurement interval MUST be configurable.

   To get correct one-way delay measurements, the two end monitoring
   nodes of the investigated segments might need to have clock
   synchronized.

4.2.3. Jitter

   Jitter over a segment is the variance of one-way delay over this
   segment during a given interval. The metric is of great importance
   for real-time streaming and interactive applications, such as IPTV,
   audio/video conferencing.

   One-way delay jitter over any segment of a multicast forwarding path
   SHOULD be able to be measured. The measurement interval MUST be
   configurable.

   To get correct jitter statistics, the clock frequencies at the two
   end monitoring nodes might need to be synchronized so that the clocks
   at two systems will proceed at the same pace.

4.2.4. Throughput

   Throughput of multicast traffic for a group over a segment is the
   average number of bytes of user packets of this multicast group
   transmitted over this segment in unit time during a given interval.
   The information might be useful for resource management.


Bianchetti, et al.     Expires January 6, 2010                [Page 7]


Internet-Draft      IP Multicast PM requirements             July 2009


   Throughput of multicast traffic over any segment of a multicast
   forwarding path MAY be measured. The measurement interval MUST be
   configurable.

4.3. Measurement session management

   A measurement session refers to the period of time in which
   measurement for certain performance metrics is enabled over a segment
   of multicast forwarding path or over a complete multicast forwarding
   path. During a measurement session, the two end interfaces are said
   active. When an interface is activated, the interfaces start
   collecting statistics, such as number or timestamps of user packets
   which belongs to the given multicast group and pass through the
   interface. When both interfaces are activated, the measurement
   session starts. During a measurement session, statistics from two
   active interfaces are periodically correlated and the performance
   metrics, such as loss rate or delay, are derived. The correlation can
   be done either on the downstream interface if the upstream interface
   passes its statistics to it or on a third-party if the raw statistics
   on two active interfaces are reported to it. When one of the two
   interfaces is deactivated, the measurement session stops.

4.3.1. Segment v.s. Path

   Network operators SHOULD be able to turn on or off measurements
   sessions for specific performance metrics over either a segment of
   multicast forwarding path or over a complete multicast forwarding
   path at any time. For example in Figure 1, network operator can turn
   on the measurement session of loss rate over path A-B-D-F and segment
   A-B-C as well as jitter over segment C-E-G-I simultaneously. This
   feature allows network operators to zoom into the suspicious
   components when degradation or failure occurs.

4.3.2. Static v.s. Dynamic configuration

   A measurement session can be configured statically. In this case,
   network operators activate the two interfaces or configure their
   parameter settings on the relevant nodes either manually or
   automatically through agents of network management system (NMS).

   Optionally, a measurement session can be configured dynamically. In
   this case, an interface may coordinate another interface on its
   forwarding path to start or stop a session. Accordingly, the format
   and process routines of the measurement session control packets need
   to be specified. The delivery of such packets SHOULD be reliable and
   MUST be secured.



Bianchetti, et al.     Expires January 6, 2010                [Page 8]


Internet-Draft      IP Multicast PM requirements             July 2009


4.3.3. Proactive v.s. on-demand

   A measurement session can be started either proactively or on demand.
   To save resources, operators may turn on measurement sessions
   proactively for critical performance metrics over the backbone
   segments of multicast forwarding tree only. This keeps the overall
   monitoring overhead minimal during normal network operations. However,
   when network performance degradation or service disruption occurs,
   operators might turn on measurement sessions on demand over the
   interested segments to facilitate fault localization.

4.4. Measurement result report

   The measurement results might be present in two forms: reports or
   alarms.

4.4.1. Performance reports

   Performance reports contain streams of continuous measurement data
   over a period of time. A data collection agent MAY actively poll the
   monitoring nodes and collect the measurement reports from all active
   interfaces. Alternatively, the monitoring nodes might be configured
   to upload the reports to the specific data collection agents once the
   data become available. To save bandwidth, the content of the reports
   might be aggregated and compressed. The period of reporting SHOULD be
   able to be configured or controlled by rate limitation mechanisms
   (e.g., exponentially increasing).

4.4.2. Exceptional alarms

   On the other hand, the active interfaces of a monitoring node MAY be
   configured to raise alarms if exceptional events such as performance
   degradation or service disruption occur. During the meantime, the
   monitoring node remains quiescent. In this configuration, alarm
   thresholds and the nodes to which alarms are reported should be
   specified for each of the performance metric when the measurement
   session is configured on this interface. During measurement session,
   once the performance metric exceeds the threshold, alarm will be
   raised and reported to the configured nodes. To prevent huge volume
   of alarms from overloading the management nodes and congest the
   network, suppression and aggregation mechanisms SHOULD be employed on
   the interfaces to limit the rate of alarm report and the volume of
   data.






Bianchetti, et al.     Expires January 6, 2010                [Page 9]


Internet-Draft      IP Multicast PM requirements             July 2009


5. Design considerations

   To make the monitoring system feasible for a SP production network,
   the designers should take into account the following requirements.

5.1. Inline data-plane measurement

   The system is monitoring the performance of multicast traffic, and
   thus is operating on data plane. The performance measurement should
   be ``inline'' in the sense that the measurement statistics are
   derived directly from user packets, instead of probing packets. At
   the same time, unlike offline packet analysis, the measurement is
   counting user packets at line-speed in real-time without any packet
   duplication or buffering.

   Probing packet SHOULD be avoided in performance measurement.
   Measurement results collected by probing packets might be biased or
   even totally irrelevant given the facts that (1) probing packets
   collect sampled results only and might not capture the real statistic
   characteristics of the monitored user traffic. Experiments have
   demonstrated that the measurement sampled by the probing packets,
   such as ping probes, might be incorrect if sampling interval is too
   long [1]; (2) probing packets introduce extra load onto the network.
   In order to improve accuracy, sampling frequency has to be high
   enough, which in turn increase network overhead and further bias the
   measurement results; (3) probing packets are usually not in the same
   multicast group as user packets and might take different forwarding
   path given that equal cost multi-path routing (ECMP) and link
   aggregation (LAG) have been widely adopted in SP network. An out-of-
   band probing packet might take a path totally different from the user
   packets of the multicast group that it is monitoring. Even if the
   forwarding path is the same, the intermediate node might apply
   different queuing and scheduling strategy for the probing packets. As
   a result, the measured results might be irrelevant.

   To accomplish the inline measurement, some extra packets might need
   to be injected into user traffic to coordinate measurement across
   nodes. The volume of these packets SHOULD be keep minimal such that
   the injection of such packets will not impact measurement accuracy.

5.2. Scalability

   The measurement methodology and system architecture MUST be scalable.
   A multicast network for SP is usually composed of thousands of nodes.
   Given the scale, the collecting, processing and reporting overhead of
   performance statistic data SHOULD not overwhelm either monitoring



Bianchetti, et al.     Expires January 6, 2010               [Page 10]


Internet-Draft      IP Multicast PM requirements             July 2009


   nodes or management nodes. The volume of reporting traffic should be
   reasonable and not cause any network congestion.

5.3. Robustness

   The measurements MUST be fault-free, namely, independent of the
   failure of the underlying multicast network. For example, the monitor
   SHOULD generate correct measurement result even if some measurement
   coordinating packets are lost; invalid performance reports should be
   able to be identified in case that the underlying multicast network
   is undergoing drastic changes.

   If dynamic configuration is supported, the delivery of measurement
   session control packets SHOULD be reliable so that the measurement
   sessions can be started, ended and performed in a predictable manner.
   Meanwhile, the packets SHOULD be multicast independent as the packets
   should not use multicast to delivery. This guarantees that the active
   interfaces are still under control even if the multicast service is
   malfunctioning.

   Similarly, if NMS are used to control the monitoring nodes remotely,
   the communication between them SHOULD be reliable and multicast
   independent.

5.4. Security

   The monitoring system MUST not impose security risks on the network.
   For example, the monitoring nodes should not be exploited by third
   parties to control measurement sessions arbitrarily. This might leave
   holes for DDoS attacks.

   If dynamic configuration is supported, the measurement session
   control packets need to be encrypted and authenticated.

5.5. Device flexibility

   The deployment requirement in terms of both software and hardware
   SHOULD be reasonable. For example, one-way delay measurement needs
   clock synchronization across nodes. To require all nodes to install
   expensive hardware clock synchronization devices might be too costly
   to make the monitoring system infeasible for large deployment.

   The monitor system SHOULD be incrementally deployable, which means
   that the system can enable monitoring functionality even if some of
   the nodes in the network are not equipped with the required software
   and hardware or does not meet the software and hardware deployment
   requirements.


Bianchetti, et al.     Expires January 6, 2010               [Page 11]


Internet-Draft      IP Multicast PM requirements             July 2009


   The non-monitoring nodes without the monitoring capabilities SHOULD
   be able to coexist with monitoring nodes and function. The packets
   exchanged between monitoring nodes SHOULD be transparent to other
   nodes and MUST not cause any malfunction of the non-monitoring nodes.

5.6. Extensibility

   The system should be easy to extend for new functionalities. For
   example, the system should be easily extended to collect newly
   defined performance metrics.

6. Security Considerations

   The security issues have been taken into account in design
   considerations.

7. IANA Considerations

   There is no IANA action required by this draft.

8. References

8.1. Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]  Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
         Specifications: ABNF", RFC 2234, Internet Mail Consortium and
         Demon Internet Ltd., November 1997.

8.2. Informative References

   [3]  "Trading Floor Architecture", White Paper , Online
         http://www.cisco.com/en/US/docs/solutions/Verticals/Trading_Flo
         or_Architecture-E.html.

   [4]  Venaas, S., "Multicast Ping Protocol", draft-ietf-mboned-
         ssmping-07, December 2008.

   [5]  Asaeda, H., Jinmei, T., Fenner, W., and S. Casner, "Mtrace
         Version 2: Traceroute Facility for IP Multicast", draft-ietf-
         mboned-mtrace-v2-03, March 2009.

   [6]  Almeroth, K., Wei, L., and D. Farinacci, "Multicast
         Reachability Monitor (MRM)", draft-ietf-mboned-mrm-01, July
         2000.


Bianchetti, et al.     Expires January 6, 2010               [Page 12]


Internet-Draft      IP Multicast PM requirements             July 2009


   [7]  Bacher, D., Swan, A., and L. Rowe, "rtpmon: a third-party RTCP
         monitor", Conference 4th ACM International conference on
         multimedium, 1997.

   [8]  Sarac, K. and K. Almeroth, "Application Layer Reachability
         Monitoring for IP Multicast", Journal Computer Networks Journal,
         Vol.48, No.2, pp.195-213, June 2005.

   [9]  Rajvaidya, P., Almeroth, K., and k. claffy, "A Scalable
         Architecture for Monitoring and Visualizating Multicast
         Statistics", Conference IFIP/IEEE Workshop on Distributed
         Systems: Operations & Management (DSOM), Austin, Texas, USA,
         December 2000.

   [10] Sharma, P., Perry, E., and R. Malpani, "IP Multicast
         Operational Network Management: Design, Challenges and
         Experiences", Journal IEEE Network, Volume 17, Issue 2, Mar/Apr
         2003 Page(s): 49 - 55, Mar/Apr 2003.

   [11] Al-Shaer, E. and Y. Tang, "MRMON: Remote Multicast Monitoring",
         Conference NOMS, 2004.

   [12] Sarac, K. and K. Almeroth, "Supporting Multicast Deployment
         Efforts: A Survey of Tools for Multicast Monitoring", Journal
         Journal of High Speed Networks, Vol.9, No.3-4, pp.191-211, 2000.

   [13] Sarac, K. and K. Almeroth, "Monitoring IP Multicast in the
         Internet: Recent Advances and Ongoing Challenges", Journal IEEE
         Communication Magazine, 2005.

   [14] Vit Novotny, Dan Komosny, "Optimization of Large-Scale RTCP
         Feedback Reporting in Fixed and Mobile Networks," icwmc, pp.85,
         Third International Conference on Wireless and Mobile
         Communications (ICWMC'07), 2007

9. Acknowledgments

   The authors would like to thank Wei Cao, Xinchun Guo, and Hui Liu for
   their helpful comments and discussions.

   This document was prepared using 2-Word-v2.0.template.dot.








Bianchetti, et al.     Expires January 6, 2010               [Page 13]


Internet-Draft      IP Multicast PM requirements             July 2009


Authors' Addresses

   Mario Bianchetti
   Broadband Network Services Innovation, Telecom Italia

   Email: mario.bianchetti@telecomitalia.it


   Giovanni Picciano
   Access Network Engineering, Telecom Italia

   Email: giovanni.picciano@telecomitalia.it


   Mach(Guoyi) Chen
   Huawei Technologies Co.,Ltd
   KuiKe Building, No.9 Xinxi Rd.,
   Hai-Dian District
   Beijing, 100085
   P.R. China

   EMail: mach@huawei.com


   Jian Qiu
   Huawei Technology CO. LTD.
   No. 9 Xinxi Road
   Shangdi Information Industry Base
   Hai-Dian District, Beijing  100085
   China

   Email: qj@huawei.com
















Bianchetti, et al.     Expires January 6, 2010               [Page 14]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/