summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6754.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6754.txt')
-rw-r--r--doc/rfc/rfc6754.txt675
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc6754.txt b/doc/rfc/rfc6754.txt
new file mode 100644
index 0000000..50fb29a
--- /dev/null
+++ b/doc/rfc/rfc6754.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) Y. Cai
+Request for Comments: 6754 Microsoft
+Category: Standards Track L. Wei
+ISSN: 2070-1721 H. Ou
+ Cisco Systems, Inc.
+ V. Arya
+ S. Jethwani
+ DIRECTV Inc.
+ October 2012
+
+
+ Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect
+
+Abstract
+
+ A Protocol Independent Multicast (PIM) router uses the Reverse Path
+ Forwarding (RPF) procedure to select an upstream interface and router
+ in order to build forwarding state. When there are equal-cost
+ multipaths (ECMPs), existing implementations often use hash
+ algorithms to select a path. Such algorithms do not allow the spread
+ of traffic among the ECMPs according to administrative metrics. This
+ usually leads to inefficient or ineffective use of network resources.
+ This document introduces the ECMP Redirect, a mechanism to improve
+ the RPF procedure over ECMPs. It allows ECMP selection to be based
+ on administratively selected metrics, such as data transmission
+ delays, path preferences, and routing metrics.
+
+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.
+
+ 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/rfc6754.
+
+
+
+
+
+
+
+
+
+
+
+Cai, et al. Standards Track [Page 1]
+
+RFC 6754 PIMv2 ECMP Redirect October 2012
+
+
+Copyright Notice
+
+ 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.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 5. Protocol Specification . . . . . . . . . . . . . . . . . . . . 6
+ 5.1. Sending ECMP Redirect . . . . . . . . . . . . . . . . . . 6
+ 5.2. Receiving ECMP Redirect . . . . . . . . . . . . . . . . . 7
+ 5.3. Transient State . . . . . . . . . . . . . . . . . . . . . 7
+ 5.4. Interoperability . . . . . . . . . . . . . . . . . . . . . 8
+ 5.5. Packet Format . . . . . . . . . . . . . . . . . . . . . . 8
+ 5.5.1. PIM ECMP Redirect Hello Option . . . . . . . . . . . . 8
+ 5.5.2. PIM ECMP Redirect Format . . . . . . . . . . . . . . . 9
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
+ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cai, et al. Standards Track [Page 2]
+
+RFC 6754 PIMv2 ECMP Redirect October 2012
+
+
+1. Introduction
+
+ A PIM router uses the RPF procedure to select an upstream interface
+ and a PIM neighbor on that interface to build forwarding state. When
+ there are equal-cost multipaths (ECMPs) upstream, existing
+ implementations often use hash algorithms to select a path. Such
+ algorithms do not allow the spread of traffic among the ECMP
+ according to administrative metrics. This usually leads to
+ inefficient or ineffective use of network resources. This document
+ introduces the ECMP Redirect, a mechanism to improve the RPF
+ procedure over ECMP. It allows ECMP selection to be based on
+ administratively selected metrics, such as data transmission delays,
+ path preferences, and routing metrics, or a combination of metrics.
+
+ ECMPs are frequently used in networks to provide redundancy and to
+ increase available bandwidth. A PIM router selects a path in the
+ ECMP based on its own implementation-specific choice. The selection
+ is a local decision. One way is to choose the PIM neighbor with the
+ highest IP address; another is to pick the PIM neighbor with the best
+ hash value over the destination and source addresses.
+
+ While implementations supporting ECMP have been deployed widely, the
+ existing RPF selection methods have weaknesses. The lack of
+ administratively effective ways to allocate traffic over alternative
+ paths is a major issue. For example, there is no straightforward way
+ to tell two downstream routers to select either the same or different
+ RPF neighbor routers for the same traffic flows.
+
+ With the ECMP Redirect mechanism introduced here, the upstream
+ routers use a PIM ECMP Redirect message to instruct the downstream
+ routers on how to tiebreak among the upstream neighbors. The PIM
+ ECMP Redirect message conveys the tiebreak information based on
+ metrics selected administratively.
+
+2. Terminology
+
+ 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].
+
+ This document uses terms defined in [RFC4601] to describe actions
+ taken by PIM routers.
+
+ The following terms have special significance for ECMP Redirect:
+
+ o Equal-Cost Multipath (ECMP). In this document, the term "ECMP"
+ refers to parallel, single-hop, equal-cost links between adjacent
+ nodes.
+
+
+
+Cai, et al. Standards Track [Page 3]
+
+RFC 6754 PIMv2 ECMP Redirect October 2012
+
+
+ o ECMP Bundle. An ECMP bundle is a set of PIM-enabled interfaces on
+ a router, where all interfaces belonging to the same bundle share
+ the same routing metric. The next hops for the ECMP are all one
+ hop away.
+
+ There can be one or more ECMP bundles on any router, while one
+ individual interface can only belong to a single bundle. ECMP
+ bundles are created on a router via configuration.
+
+ o RPF. RPF stands for Reverse Path Forwarding.
+
+ o Upstream. Towards the root of the multicast forwarding tree. An
+ upstream router refers to a router that is forwarding, or
+ potentially capable of forwarding, data packets onto interfaces in
+ an ECMP bundle.
+
+ When there are multiple routers forwarding packets onto interfaces
+ in the ECMP bundle, all these routers are called upstream routers.
+
+ o Downstream. Away from the root of the multicast forwarding tree.
+ A downstream router is a router that uses an interface in the ECMP
+ bundle as an RPF interface for a multicast forwarding entry.
+
+3. Overview
+
+ The existing PIM Assert mechanism allows the upstream router to
+ detect the existence of multiple forwarders for the same multicast
+ flow onto the same downstream interface. The upstream router sends a
+ PIM Assert message containing a routing metric for the downstream
+ routers to use for tiebreaking among the multiple upstream forwarders
+ on the same RPF interface.
+
+ With ECMP interfaces between the downstream and upstream routers, the
+ PIM ECMP Redirect mechanism works in a similar way, but extends the
+ ability to resolve the selection of forwarders among different
+ interfaces in the ECMP.
+
+ When a PIM router downstream of the ECMP interfaces creates a new
+ (*,G) or (S,G) entry, it will populate the RPF interface and RPF
+ neighbor information according to the rules specified by [RFC4601].
+ This router will send its initial PIM Joins to that RPF neighbor.
+
+ When the RPF neighbor router receives the Join message and finds that
+ the receiving interface is one of the ECMP interfaces, it will check
+ if the same flow is already being forwarded out of another ECMP
+ interface. If so, this RPF neighbor router will send a PIM ECMP
+ Redirect message onto the interface the Join was received on. The
+ PIM ECMP Redirect message contains the address of the desired RPF
+
+
+
+Cai, et al. Standards Track [Page 4]
+
+RFC 6754 PIMv2 ECMP Redirect October 2012
+
+
+ neighbor, an Interface ID [RFC6395], and the other parameters used as
+ tiebreakers. In essence, a PIM ECMP Redirect message is sent by an
+ upstream router to notify downstream routers to redirect PIM Joins to
+ the new RPF neighbor via a different interface. When the downstream
+ routers receive this message, they SHOULD trigger PIM Joins toward
+ the new RPF neighbor specified in the packet.
+
+ This PIM ECMP Redirect message has similar functions as the existing
+ PIM Assert message:
+
+ 1. It is sent by an upstream router.
+
+ 2. It is used to influence the RPF selection by downstream routers.
+
+ 3. A tiebreaker metric is used.
+
+ However, the existing Assert message is used to select an upstream
+ router within the same multi-access network (such as a LAN), while
+ the Redirect message is used to select both a network and an upstream
+ router.
+
+ One advantage of this design is that the control messages are only
+ sent when there is a need to "rebalance" the traffic. This reduces
+ the amount of control traffic.
+
+4. Applicability
+
+ The use of ECMP Redirect applies to shared trees or source trees
+ built with procedures described in [RFC4601]. The use of ECMP
+ Redirect in PIM Dense Mode [RFC3973] or in Bidirectional PIM
+ [RFC5015] is not considered in this document.
+
+ The enhancement described in this document can be applicable to a
+ number of scenarios. For example, it allows a network operator to
+ use ECMPs and have the ability to perform load splitting based on
+ bandwidth. To do this, the downstream routers perform RPF selection
+ with bandwidth, instead of IP addresses, as a tiebreaker. The ECMP
+ Redirect mechanism assures that all downstream routers select the
+ desired network link and upstream router whenever possible. Another
+ example is for a network operator to impose a transmission delay
+ limit on certain links. The ECMP Redirect mechanism provides a means
+ for an upstream router to instruct a downstream router to choose a
+ different RPF path.
+
+ This specification does not dictate the scope of applications of this
+ mechanism.
+
+
+
+
+
+Cai, et al. Standards Track [Page 5]
+
+RFC 6754 PIMv2 ECMP Redirect October 2012
+
+
+5. Protocol Specification
+
+5.1. Sending ECMP Redirect
+
+ ECMP Redirects are sent by an upstream router in a rate-limited
+ fashion, under either of the following conditions:
+
+ o It detects a PIM Join on a non-desired outgoing interface.
+
+ o It detects multicast traffic on a non-desired outgoing interface.
+
+ In both cases, an ECMP Redirect is sent to the non-desired interface.
+ An outgoing interface is considered "non-desired" when:
+
+ o The upstream router is already forwarding the same flow out of
+ another interface belonging to the same ECMP bundle.
+
+ o The upstream router is not yet forwarding the flow out any
+ interfaces of the ECMP bundle, but there is another interface with
+ more desired attributes.
+
+ An upstream router MAY choose not to send ECMP Redirects if it
+ becomes aware that some of the downstream routers are unreachable via
+ some links in ECMP bundle.
+
+ An upstream router uses the Neighbor Address or the Interface ID
+ field in the ECMP Redirect message to indicate the interface it wants
+ traffic to be directed to. This Neighbor Address MUST be associated
+ with an interface in the same ECMP bundle as the ECMP Redirect
+ message's outgoing interface. If the Interface ID field is ignored,
+ this Neighbor Address field uniquely identifies a LAN and an upstream
+ router to which a downstream router SHOULD redirect its Join
+ messages, and an ECMP Redirect message MUST be discarded if the
+ Neighbor Address field in the message does not match the cached
+ neighbor address.
+
+ The Interface ID field is used in IPv4 when one or more RPF neighbors
+ in the ECMP bundle are unnumbered, or in IPv6 where link-local
+ addresses are in use. For other IPv4 usage, this field is zeroed
+ when sent, and ignored when received. If the Router ID part of the
+ Interface ID is zero, the field MUST be ignored. See [RFC6395] for
+ details of its assignment and usage in PIM Hellos. If the Interface
+ ID is not ignored, the receiving router of this message MUST use the
+ Interface ID, instead of Neighbor Address, to identify the new RPF
+ neighbor. Additionally, an ECMP Redirect message MUST be discarded
+ if the Interface ID field in the message does not match the cached
+ Interface ID.
+
+
+
+
+Cai, et al. Standards Track [Page 6]
+
+RFC 6754 PIMv2 ECMP Redirect October 2012
+
+
+5.2. Receiving ECMP Redirect
+
+ When a downstream router receives an ECMP Redirect, and detects that
+ the desired RPF path from its upstream router's point of view is
+ different from its current one, it should choose to join the newly
+ suggested path and prune from the current path. The exact order of
+ such actions is implementation specific.
+
+ If a downstream router receives multiple ECMP Redirects sent by
+ different upstream routers, it SHOULD use the Preference, Metric, or
+ other fields as specified below as the tiebreakers to choose the most
+ preferred RPF interface and neighbor. The tiebreak procedure is the
+ same as that used in PIM Assert processing described by [RFC4601].
+
+ If an upstream router receives an ECMP Redirect, it SHOULD NOT change
+ its forwarding behavior even if the ECMP Redirect makes it a less
+ preferred RPF neighbor on the receiving interface.
+
+5.3. Transient State
+
+ During a transient network outage with a single link cut in an ECMP
+ bundle, a downstream router may lose connection to its RPF neighbor
+ and the normal ECMP Redirect operation may be interrupted
+ temporarily. In such an event, the following actions are
+ RECOMMENDED.
+
+ The downstream router SHOULD select a new RPF neighbor. Among all
+ ECMP upstream routers, the preferred selection is the one on the LAN
+ that the previous RPF neighbor resided on.
+
+ If there is no upstream router reachable on the LAN that the previous
+ RPF neighbor resided on, the downstream router will select a new RPF
+ neighbor on a different LAN. Among all ECMP upstream routers, the
+ one that served as RPF neighbor before the link failure is preferred.
+ Such a router can be identified by the Router ID, which is part of
+ the Interface ID in the PIM ECMP Redirect Hello option.
+
+ During normal ECMP Redirect operations, when PIM Joins for the same
+ (*,G) or (S,G) are received on a different LAN, an upstream router
+ will send ECMP Redirect to prune the non-preferred LAN. Such ECMP
+ Redirects during partial network outage can be suppressed if the
+ upstream router decides that the non-preferred PIM Join is from a
+ router that is not reachable via the preferred LAN. This check can
+ be performed by retrieving the downstream router's Router ID, using
+ the source address in the PIM Join, and searching neighbors on the
+ preferred LAN for one with the same Router ID.
+
+
+
+
+
+Cai, et al. Standards Track [Page 7]
+
+RFC 6754 PIMv2 ECMP Redirect October 2012
+
+
+5.4. Interoperability
+
+ If a PIM router supports this specification, it MUST send the PIM
+ ECMP Redirect Hello Option in its PIM Hello messages.
+
+ A PIM router sends ECMP Redirects on an interface only when it
+ detects that all neighbors on that interface have sent this Hello
+ option. If a PIM router detects that any of its neighbors on an ECMP
+ bundle does not support this Hello option, it SHOULD NOT send ECMP
+ Redirects to interfaces in that bundle; however, it SHOULD still
+ process any ECMP Redirects received from interfaces in that same
+ bundle.
+
+ If a PIM router does not support this specification, it will ignore
+ the PIM ECMP Redirect Hello Options and ECMP Redirects in the PIM
+ packets that it receives.
+
+5.5. Packet Format
+
+5.5.1. PIM ECMP Redirect Hello Option
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type = 32 | Length = 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1: ECMP Redirect Hello Option
+
+ Type: 32
+
+ Length: 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cai, et al. Standards Track [Page 8]
+
+RFC 6754 PIMv2 ECMP Redirect October 2012
+
+
+5.5.2. PIM ECMP Redirect Format
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |PIM Ver| Type | Reserved | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Group Address (Encoded-Group format) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Source Address (Encoded-Unicast format) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Neighbor Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ +-+-+-+-+-+- ............ Interface ID ........... -+-+-+-+-+-+-+
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Preference | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-- ... Metric ... -+-+-+-+-+-+-+-+-+
+ | |
+ +- .. Metric .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ +-+-+-+-+-+-+-+-+
+
+ Figure 2: ECMP Redirect Message Format
+
+ PIM Ver: See Section 4.9 in [RFC4601].
+
+ Type: 11
+
+ Reserved: See Section 4.9 in [RFC4601].
+
+ Checksum: See Section 4.9 in [RFC4601].
+
+ Group Address (64 or 160 bits): Encoded-Group address as specified
+ in Section 4.9.1 of [RFC4601].
+
+ Source Address (48 or 144 bits): Encoded-Unicast address as
+ specified in Section 4.9.1 of [RFC4601].
+
+ Neighbor Address (32 or 128 bits): Address of desired upstream
+ neighbor where the downstream receiver redirects PIM Joins.
+
+ Interface ID (64 bits): See [RFC6395] for details.
+
+
+
+
+
+
+
+Cai, et al. Standards Track [Page 9]
+
+RFC 6754 PIMv2 ECMP Redirect October 2012
+
+
+ Preference (8 bits): The first tiebreaker when ECMP Redirects from
+ multiple upstream routers are compared against each other. A
+ numerically smaller value is preferred. A reserved value (15) is
+ used to indicate the metric value following the Preference field
+ is a Network Time Protocol (NTP) timestamp, encoded in the format
+ specified in [RFC5905], taken at the moment the sending router
+ started to forward out of this interface.
+
+ Metric (64 bits): The second tiebreaker if the Preference values are
+ the same. A numerically smaller value is preferred. This Metric
+ can contain path parameters defined by users. When the Preference
+ and Metric values are the same, the Neighbor Address or Interface
+ ID field is used as the third tiebreaker, depending on which field
+ is used to identify the RPF neighbor; the bigger value wins.
+
+6. IANA Considerations
+
+ A PIM-Hello Option Type (32) has been assigned to the PIM ECMP
+ Redirect Hello Option.
+
+ In the PIM Message Types registry created by [RFC6166], a PIM Message
+ Type (11) has been assigned to the ECMP Redirect message.
+
+7. Security Considerations
+
+ Security of the ECMP Redirect is only guaranteed by the security of
+ the PIM packet; the security considerations for PIM Assert packets as
+ described in [RFC4601] apply here. Spoofed ECMP Redirect packets may
+ cause the downstream routers to send PIM Joins to an undesired
+ upstream router and trigger more ECMP Redirect messages. Security
+ considerations for PIM packets described in [RFC4601] also apply to
+ the new Hello option defined here.
+
+8. Acknowledgements
+
+ The authors would like to thank Apoorva Karan for helping with the
+ original idea, and Eric Rosen, Isidor Kouvelas, Toerless Eckert, Stig
+ Venaas, Jeffrey Zhang, Bill Atwood, and Adrian Farrel for their
+ review comments.
+
+
+
+
+
+
+
+
+
+
+
+
+Cai, et al. Standards Track [Page 10]
+
+RFC 6754 PIMv2 ECMP Redirect October 2012
+
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
+ "Protocol Independent Multicast - Sparse Mode (PIM-SM):
+ Protocol Specification (Revised)", RFC 4601, August 2006.
+
+9.2. Informative References
+
+ [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
+ Independent Multicast - Dense Mode (PIM-DM): Protocol
+ Specification (Revised)", RFC 3973, January 2005.
+
+ [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
+ "Bidirectional Protocol Independent Multicast (BIDIR-
+ PIM)", RFC 5015, October 2007.
+
+ [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
+ "Network Time Protocol Version 4: Protocol and Algorithms
+ Specification", RFC 5905, June 2010.
+
+ [RFC6166] Venaas, S., "A Registry for PIM Message Types", RFC 6166,
+ April 2011.
+
+ [RFC6395] Gulrajani, S. and S. Venaas, "An Interface Identifier (ID)
+ Hello Option for PIM", RFC 6395, October 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cai, et al. Standards Track [Page 11]
+
+RFC 6754 PIMv2 ECMP Redirect October 2012
+
+
+Authors' Addresses
+
+ Yiqun Cai
+ Microsoft
+ 1065 La Avenida
+ Mountain View, CA 94043
+ USA
+
+ EMail: yiqunc@microsoft.com
+
+
+ Liming Wei
+ Cisco Systems, Inc.
+ Tasman Drive
+ San Jose, CA 95134
+ USA
+
+ EMail: lwei@cisco.com
+
+
+ Heidi Ou
+ Cisco Systems, Inc.
+ Tasman Drive
+ San Jose, CA 95134
+ USA
+
+ EMail: hou@cisco.com
+
+
+ Vishal Arya
+ DIRECTV Inc.
+ 2230 E Imperial Hwy
+ El Segundo, CA 90245
+ USA
+
+ EMail: varya@directv.com
+
+
+ Sunil Jethwani
+ DIRECTV Inc.
+ 2230 E Imperial Hwy
+ El Segundo, CA 90245
+ USA
+
+ EMail: sjethwani@directv.com
+
+
+
+
+
+
+Cai, et al. Standards Track [Page 12]
+