Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 7104 Cisco
Category: Standards Track Y. Cai
ISSN: 2070-1721 Microsoft
H. Ou
Cisco
January 2014
Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 7104 Cisco
Category: Standards Track Y. Cai
ISSN: 2070-1721 Microsoft
H. Ou
Cisco
January 2014
Duplication Grouping Semantics in the Session Description Protocol
会话描述协议中的复制分组语义
Abstract
摘要
Packet loss is undesirable for real-time multimedia sessions, but it can occur due to congestion or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document defines the semantics for grouping redundant streams in the Session Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework. Grouping semantics at the Synchronization Source (SSRC) level are also defined in this document for RTP streams using SSRC multiplexing.
对于实时多媒体会话，数据包丢失是不可取的，但它可能是由于拥塞或其他计划外的网络中断而发生的。这对于IP多播网络尤其如此，因为在IP多播网络中，数据包丢失模式在不同的接收器之间可能会有很大的差异。一种可用于从数据包丢失中恢复而不会对所有接收器产生无界延迟的技术是复制数据包并在单独的冗余流中发送它们。本文档定义了会话描述协议（SDP）中分组冗余流的语义。本文档中定义的语义将与SDP分组框架一起使用。本文档还为使用SSRC多路复用的RTP流定义了同步源（SSRC）级别的分组语义。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7104.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7104.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Requirements Notation ...........................................3
3. Duplication Grouping ............................................3
3.1. "DUP" Grouping Semantics ...................................3
3.2. Duplication Grouping for SSRC-Multiplexed RTP Streams ......3
3.3. SDP Offer/Answer Model Considerations ......................4
4. SDP Examples ....................................................5
4.1. Separate Source Addresses ..................................5
4.2. Separate Destination Addresses .............................6
4.3. Temporal Redundancy ........................................7
5. Security Considerations .........................................7
6. IANA Considerations .............................................8
7. Acknowledgments .................................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................9
1. Introduction ....................................................2
2. Requirements Notation ...........................................3
3. Duplication Grouping ............................................3
3.1. "DUP" Grouping Semantics ...................................3
3.2. Duplication Grouping for SSRC-Multiplexed RTP Streams ......3
3.3. SDP Offer/Answer Model Considerations ......................4
4. SDP Examples ....................................................5
4.1. Separate Source Addresses ..................................5
4.2. Separate Destination Addresses .............................6
4.3. Temporal Redundancy ........................................7
5. Security Considerations .........................................7
6. IANA Considerations .............................................8
7. Acknowledgments .................................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................9
The Real-time Transport Protocol (RTP) [RFC3550] is widely used today for delivering IPTV traffic and other real-time multimedia sessions. Many of these applications support very large numbers of receivers and rely on intra-domain UDP/IP multicast for efficient distribution of traffic within the network.
实时传输协议（RTP）[RFC3550]目前广泛用于传输IPTV流量和其他实时多媒体会话。其中许多应用程序支持大量的接收器，并依靠域内UDP/IP多播在网络内高效地分配流量。
While this combination has proved successful, there does exist a weakness. As [RFC2354] noted, packet loss is not avoidable, even in a carefully managed network. This loss might be due to congestion; it might also be a result of an unplanned outage caused by a flapping link, a link or interface failure, a software bug, or a maintenance person accidentally cutting the wrong fiber. Since UDP/IP flows do not provide any means for detecting loss and retransmitting packets, it is left up to the RTP layer and the applications to detect, and recover from, packet loss.
虽然这一组合被证明是成功的，但确实存在一个弱点。正如[RFC2354]所指出的，即使在精心管理的网络中，数据包丢失也是无法避免的。这种损失可能是由于交通拥挤造成的；这也可能是由于链路抖动、链路或接口故障、软件错误或维护人员意外切断错误光纤而导致的意外中断。由于UDP/IP流不提供任何检测丢失和重新传输数据包的方法，因此由RTP层和应用程序来检测和恢复数据包丢失。
One technique to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. Variations on this idea have been implemented and deployed today [IC2011]. [RTP-DUP] explains how duplication can be achieved for RTP streams without breaking the RTP and RTP Control Protocol (RTCP) functionality. In this document, we describe the semantics needed in the Session Description Protocol (SDP) [RFC4566] to support this technique.
一种从数据包丢失中恢复而不会对所有接收器造成无界延迟的技术是复制数据包并将其发送到单独的冗余流中。这一理念的变体已经在今天实施和部署[IC2011]。[RTP-DUP]解释如何在不破坏RTP和RTP控制协议（RTCP）功能的情况下实现RTP流的复制。在本文档中，我们描述了会话描述协议（SDP）[RFC4566]中支持此技术所需的语义。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
Each "a=group" line is used to indicate an association relationship between the redundant streams. The streams included in one "a=group" line are called a "Duplication Group".
每个“a=组”行用于指示冗余流之间的关联关系。包含在一个“a=组”行中的流称为“复制组”。
Using the SDP Grouping Framework in [RFC5888], this document defines "DUP" as the grouping semantics for redundant streams.
本文档使用[RFC5888]中的SDP分组框架，将“DUP”定义为冗余流的分组语义。
The "a=group:DUP" semantics MUST be used to group the redundant streams, except when the streams are specified in the same media description, i.e., in the same "m" line (see Section 3.2). In an "a=group:DUP" line, the order of the listed redundant streams does not strictly indicate the order of transmission, although it is RECOMMENDED that the stream listed first be sent first, with the other stream(s) being the (time-delayed) duplicate(s).
“a=group:DUP”语义必须用于对冗余流进行分组，除非在相同的媒体描述中指定了流，即在相同的“m”行中（参见第3.2节）。在“a=group:DUP”行中，列出的冗余流的顺序并不严格指示传输顺序，尽管建议首先发送列出的流，而其他流是（延时的）重复流。
[RFC5576] defines an SDP media-level attribute, called "ssrc-group", for grouping the RTP streams that are SSRC multiplexed and carried in the same RTP session. The grouping is based on the SSRC identifiers. Since SSRC-multiplexed RTP streams are defined in the same "m" line, the "group" attribute cannot be used.
[RFC5576]定义了一个称为“ssrc组”的SDP媒体级属性，用于对ssrc多路复用并在同一RTP会话中传输的RTP流进行分组。分组基于SSRC标识符。由于SSRC多路复用RTP流定义在同一“m”行中，因此不能使用“group”属性。
This section explains how duplication is used with SSRC-multiplexed streams using the "ssrc-group" attribute [RFC5576].
本节说明如何使用“SSRC组”属性[RFC5576]将复制用于SSRC多路复用流。
The semantics of "DUP" for the "ssrc-group" attribute are the same as the one defined for the "group" attribute, except that the SSRC identifiers are used to designate the duplication grouping associations: a=ssrc-group:DUP *(SP ssrc-id) [RFC5576]. As above, while in an "a=ssrc-group:DUP" line, the order of the listed redundant streams does not necessarily indicate the order of transmission, but it is RECOMMENDED that the stream listed first be sent first, with the other stream(s) being the (time-delayed) duplicate(s).
“ssrc group”属性的“DUP”语义与为“group”属性定义的语义相同，只是ssrc标识符用于指定复制分组关联：a=ssrc group:DUP*（SP ssrc id）[RFC5576]。如上所述，在“a=ssrc group:DUP”行中，列出的冗余流的顺序不一定表示传输顺序，但建议首先发送列出的流，其他流为（延时）重复流。
When offering duplication grouping using SDP in an offer/answer model [RFC3264], the following considerations apply.
在报价/应答模型[RFC3264]中使用SDP提供重复分组时，应考虑以下因素。
A node that is receiving an offer from a sender may or may not understand line grouping. It is also possible that the node understands line grouping but does not understand the "DUP" semantics. From the viewpoint of the sender of the offer, these cases are indistinguishable.
从发送方接收报价的节点可能理解也可能不理解行分组。节点也可能理解行分组，但不理解“DUP”语义。从要约发送人的角度来看，这些情况无法区分。
When a node is offered a session with the "DUP" grouping semantics but it does not support line grouping or the duplication grouping semantics, as per [RFC5888], the node responds to the offer either (1) with an answer that omits the grouping attribute or (2) with a refusal to the request (e.g., "488 Not Acceptable Here" or "606 Not Acceptable in SIP").
当根据[RFC5888]向节点提供具有“DUP”分组语义的会话，但其不支持行分组或重复分组语义时，节点响应提供（1）忽略分组属性的回答或（2）拒绝请求（例如，“488此处不可接受”或“在SIP中不接受606”）。
In the first case, the original sender of the offer must send a new offer without any duplication grouping. In the second case, if the sender of the offer still wishes to establish the session, it should retry the request with an offer without the duplication grouping. This behavior is specified in [RFC5888].
在第一种情况下，要约的原始发送者必须发送一个新要约，且不存在任何重复分组。在第二种情况下，如果要约的发送方仍希望建立会话，则应使用不带重复分组的要约重试请求。[RFC5888]中规定了此行为。
In this example, the redundant streams use the same IP destination address (232.252.0.1), but they are sourced from different addresses (198.51.100.1 and 198.51.100.2). Thus, the receiving host needs to join both source-specific multicast (SSM) sessions separately.
在此示例中，冗余流使用相同的IP目标地址（232.252.0.1），但它们来自不同的地址（198.51.100.1和198.51.100.2）。因此，接收主机需要分别加入两个源特定多播（SSM）会话。
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=DUP Grouping Semantics
t=0 0
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 198.51.100.2
a=rtpmap:100 MP2T/90000
a=ssrc:1000 cname:ch1@example.com
a=ssrc:1010 cname:ch1@example.com
a=ssrc-group:DUP 1000 1010
a=mid:Ch1
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=DUP Grouping Semantics
t=0 0
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 198.51.100.2
a=rtpmap:100 MP2T/90000
a=ssrc:1000 cname:ch1@example.com
a=ssrc:1010 cname:ch1@example.com
a=ssrc-group:DUP 1000 1010
a=mid:Ch1
Note that in actual use, SSRC values, which are random 32-bit numbers, can be much larger than the ones shown in this example. Also, note that this SDP description does not use the "duplication-delay" attribute (defined in [DELAYED-DUP]) since the sender does not apply any delay between the redundant streams upon transmission. Alternatively, one MAY explicitly insert an "a=duplication-delay:0" line before the "a=mid:Ch1" line for informational purposes.
请注意，在实际使用中，SSRC值（32位随机数）可能比本例中显示的值大得多。此外，请注意，此SDP描述不使用“复制延迟”属性（在[DELAYED-DUP]中定义），因为发送方在传输时不会在冗余流之间应用任何延迟。或者，为了提供信息，可以在“a=mid:Ch1”行之前显式插入“a=replication delay:0”行。
In this example, the redundant streams have different IP destination addresses. The example shows the same UDP port number and IP source address for each stream, but either or both could have been different for the two streams.
在此示例中，冗余流具有不同的IP目标地址。该示例显示了每个流的相同UDP端口号和IP源地址，但两个流中的一个或两个可能不同。
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=DUP Grouping Semantics
t=0 0
a=group:DUP S1a S1b
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtpmap:100 MP2T/90000
a=mid:S1a
m=video 30000 RTP/AVP 101
c=IN IP4 233.252.0.2/127
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=rtpmap:101 MP2T/90000
a=mid:S1b
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=DUP Grouping Semantics
t=0 0
a=group:DUP S1a S1b
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtpmap:100 MP2T/90000
a=mid:S1a
m=video 30000 RTP/AVP 101
c=IN IP4 233.252.0.2/127
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=rtpmap:101 MP2T/90000
a=mid:S1b
Optionally, one could be more explicit and insert an "a=duplication-delay:0" line before the first "m" line.
或者，可以更明确地在第一行“m”之前插入“a=复制延迟：0”行。
In this example, the redundant streams have the same IP source and destination addresses (i.e., they are transmitted in the same SSM session). Due to the same source and destination addresses, the packets in both streams will be routed over the same path. To provide resiliency against packet loss, the duplicate of an original packet is transmitted 50 milliseconds (ms) later as indicated by the "duplication-delay" attribute (defined in [DELAYED-DUP]).
在此示例中，冗余流具有相同的IP源地址和目的地地址（即，它们在相同的SSM会话中传输）。由于相同的源地址和目标地址，两个流中的数据包将通过相同的路径路由。为了提供针对数据包丢失的弹性，原始数据包的副本将在50毫秒（ms）后传输，如“复制延迟”属性（在[DELAYED-DUP]中定义）所示。
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=Delayed Duplication
t=0 0
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtpmap:100 MP2T/90000
a=ssrc:1000 cname:ch1a@example.com
a=ssrc:1010 cname:ch1a@example.com
a=ssrc-group:DUP 1000 1010
a=duplication-delay:50
a=mid:Ch1
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=Delayed Duplication
t=0 0
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtpmap:100 MP2T/90000
a=ssrc:1000 cname:ch1a@example.com
a=ssrc:1010 cname:ch1a@example.com
a=ssrc-group:DUP 1000 1010
a=duplication-delay:50
a=mid:Ch1
In general, the security considerations of [RFC4566] apply to this document as well.
一般而言，[RFC4566]的安全注意事项也适用于本文档。
There is a weak threat for the receiver that the duplication grouping can be modified to indicate relationships that do not exist. Such attacks might result in failure of the duplication mechanisms and/or mishandling of the media streams by the receivers.
对于接收者来说，复制分组可能会被修改以指示不存在的关系，这是一个微弱的威胁。此类攻击可能导致复制机制失效和/或接收器错误处理媒体流。
In order to avoid attacks of this sort, the SDP description needs to be integrity protected and provided with source authentication. This can, for example, be achieved on an end-to-end basis using S/MIME [RFC5652] [RFC5751] when the SDP is used in a signaling packet using MIME types (application/sdp). Alternatively, HTTPS [RFC2818] or the authentication method in the Session Announcement Protocol (SAP) [RFC2974] could be used as well. As for the confidentiality, if it is desired, it can be useful to use a secure, encrypted transport method to carry the SDP description.
为了避免此类攻击，SDP描述需要完整性保护并提供源身份验证。例如，当在使用MIME类型（应用/SDP）的信令分组中使用SDP时，可以使用S/MIME[RFC5652][RFC5751]在端到端的基础上实现这一点。或者，也可以使用HTTPS[RFC2818]或会话公告协议（SAP）[RFC2974]中的身份验证方法。至于机密性，如果需要，可以使用安全、加密的传输方法来携带SDP描述。
This document registers the following semantics with IANA in the "Semantics for the "group" SDP Attribute" subregistry (under the "Session Description Protocol (SDP) Parameters" registry:
本文档在“组”SDP属性的语义”子区域（在“会话描述协议（SDP）参数”注册表下）向IANA注册以下语义：
Semantics Token Reference
------------------------------------- ------ ---------
Duplication DUP [RFC7104]
Semantics Token Reference
------------------------------------- ------ ---------
Duplication DUP [RFC7104]
This document also registers the following semantics with IANA in the "Semantics for the "ssrc-group" SDP Attribute" subregistry under the "Session Description Protocol (SDP) Parameters" registry:
本文件还在“会话描述协议（SDP）参数”注册表下的“ssrc组”SDP属性“子区域的语义”中向IANA注册以下语义：
Token Semantics Reference
------- ----------------------------- ---------
DUP Duplication [RFC7104]
Token Semantics Reference
------- ----------------------------- ---------
DUP Duplication [RFC7104]
The authors would like to thank Colin Perkins, Bill Ver Steeg, Dave Oran, and Toerless Eckert for their input and suggestions.
作者要感谢Colin Perkins、Bill Ver Steeg、Dave Oran和Toerless Eckert的投入和建议。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009.
[RFC5576]Lennox，J.，Ott，J.，和T.Schierl，“会话描述协议（SDP）中的源特定媒体属性”，RFC 55762009年6月。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5888]Camarillo，G.和H.Schulzrinne，“会话描述协议（SDP）分组框架”，RFC 5888，2010年6月。
[DELAYED-DUP] Begen, A., Cai, Y., and H. Ou, "Delayed Duplication Attribute in the Session Description Protocol", Work in Progress, December 2013.
[DELAYED-DUP]Begen，A.，Cai，Y.，和H.Ou，“会话描述协议中的延迟复制属性”，正在进行的工作，2013年12月。
[IC2011] Evans, J., Begen, A., Greengrass, J., and C. Filsfils, "Toward Lossless Video Transport, IEEE Internet Computing, vol. 15/6, pp. 48-57", November 2011.
[IC2011]Evans，J.，Begen，A.，Greengrass，J.，和C.Filsfils，“朝向无损视频传输，IEEE互联网计算，第15/6卷，第48-57页”，2011年11月。
[RFC2354] Perkins, C. and O. Hodson, "Options for Repair of Streaming Media", RFC 2354, June 1998.
[RFC2354]Perkins，C.和O.Hodson，“修复流媒体的选项”，RFC 2354，1998年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 2974，2000年10月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[RTP-DUP] Begen, A. and C. Perkins, "Duplicating RTP Streams", Work in Progress, October 2013.
[RTP-DUP]Begen，A.和C.Perkins，“复制RTP流”，正在进行的工作，2013年10月。
Authors' Addresses
作者地址
Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada
Ali Begen Cisco位于加拿大多伦多湾街181号M5J 2T3
EMail: abegen@cisco.com
EMail: abegen@cisco.com
Yiqun Cai Microsoft 1065 La Avenida Mountain View, CA 94043 USA
美国加利福尼亚州拉阿维尼达山景大道1065号益群蔡微软公司，邮编94043
EMail: yiqunc@microsoft.com
EMail: yiqunc@microsoft.com
Heidi Ou Cisco 170 W. Tasman Dr. San Jose, CA 95134 USA
Heidi Ou Cisco 170 W.Tasman博士，加利福尼亚州圣何塞，美国95134
EMail: hou@cisco.com
EMail: hou@cisco.com