AVT A. Begen Internet-Draft Cisco Systems Intended status: Standards Track March 4, 2009 Expires: September 5, 2009 RTP Payload Format for MPEG2-TS Preamble draft-begen-avt-rtp-mpeg2ts-preamble-00 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 September 5, 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. Begen Expires September 5, 2009 [Page 1] Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009 Abstract Demultiplexing and decoding an MPEG2 Transport Stream (MPEG2-TS) requires the knowledge of specific information about the transport stream, which we refer to as the MPEG2-TS Preamble. While this information is spread over different locations throughout the transport stream and can be eventually assembled after some time a receiver started receiving the MPEG2-TS, the time it takes to retrieve all this information (especially in multicast environments) may be long. Instead, having this information readily available as a Preamble and sending the Preamble to a receiver that will shortly start receiving the transport stream will virtually eliminate the waiting time and let the receiver start processing/decoding the MPEG2-TS sooner. In this document, we give an overview of the MPEG2-TS and the delay components in video systems, and motivate the need for constructing and using the MPEG2-TS Preamble for rapidly synchronizing with the source stream in RTP multicast sessions. We also define and register the RTP payload format for the MPEG2-TS Preamble. Begen Expires September 5, 2009 [Page 2] Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 6 3. Elements of Delay in Video Systems . . . . . . . . . . . . . . 7 3.1. Overview of MPEG-2 Transport Streams . . . . . . . . . . . 7 3.2. Key Information Latency in Video Applications . . . . . . 8 3.2.1. PSI (PAT/CAT/PMT) Acquisition Delay . . . . . . . . . 8 3.2.2. Random Access Point Acquisition Delay . . . . . . . . 9 3.3. Buffering Delays in Video Applications . . . . . . . . . . 10 3.3.1. Network-Related Buffering Delays . . . . . . . . . . . 10 3.3.2. Application-Related Buffering Delays . . . . . . . . . 11 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 14 5.1. Media Type Registration . . . . . . . . . . . . . . . . . 14 5.1.1. Registration of audio/mpeg2-ts-preamble . . . . . . . 14 5.1.2. Registration of video/mpeg2-ts-preamble . . . . . . . 14 5.1.3. Registration of text/mpeg2-ts-preamble . . . . . . . . 14 5.1.4. Registration of application/mpeg2-ts-preamble . . . . 14 5.2. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 14 5.2.1. Offer-Answer Model Considerations . . . . . . . . . . 15 5.2.2. Declarative Considerations . . . . . . . . . . . . . . 15 6. Session Description Protocol (SDP) Signaling . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 Begen Expires September 5, 2009 [Page 3] Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009 1. Introduction MPEG2 Transport Stream (MPEG2-TS) [MPEG2TS] is an encapsulation method and transport that multiplexes digital video and audio content, together with ancillary metadata, and produces a synchronized multiplexed stream that is tailored for transport over packet or cell-oriented networks. MPEG2-TS is ubiquitous in broadcast applications over both terrestrial and satellite networks. Both Advanced Television Systems Committee (ATSC) in North America and Digital Video Broadcasting (DVB) in Europe use MPEG2-TS in their standards. MPEG2-TS has been standardized by both ISO and ITU [MPEG2TS]. While MPEG2-TS was originally limited to carry MPEG-2 encoded content, the specification was later extended to cover MPEG- 4/AVC audio/video encoding standards as well. Due to the inherent design of MPEG2-TS, a receiver must first acquire certain information before demultiplexing and decoding an incoming MPEG2-TS. As will be explained in Section 3.1, this information resides in the transport stream. However, it is often not contiguous and is usually dispersed over a large period. Thus, a receiver starting to receive an MPEG2-TS at a random location will have to wait until the whole required information shows up in the received data. In multicast applications, since the joining receivers do not have any control over what point in the flow is currently being transmitted, their waiting times will vary. This problem has been identified and examined in detail in [I-D.versteeg-avt-rapid-synchronization-for-rtp], where the time lag before a receiver can usefully consume the multicast data is referred to as the Synchronization Delay. Section 3 provides an overview of the delay components in video systems that contribute to the synchronization delay. [I-D.versteeg-avt-rapid-synchronization-for-rtp] refers to the information that must first be acquired before starting to process any data sent in the multicast session as the Key Information. In this document, we refer to the subset of the key information that is related to the MPEG2-TS as the MPEG2-TS Preamble. For multicast applications running over RTP, [I-D.versteeg-avt-rapid-synchronization-for-rtp] proposes an approach where an auxiliary unicast RTP session is established between a retransmission server and the joining RTP receiver. Over this unicast RTP session, the retransmission server provides the key information the RTP receiver needs to rapidly synchronize with the multicast session. If the source stream in the RTP multicast session is carrying an MPEG2-TS, the key information will comprise the MPEG2-TS Preamble as well. For its proper transmission from the retransmission server to the joining RTP receiver, a new RTP payload Begen Expires September 5, 2009 [Page 4] Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009 format has to be defined for the MPEG2-TS Preamble. This document defines and registers this payload format. Begen Expires September 5, 2009 [Page 5] Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009 2. Requirements Notation 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]. Begen Expires September 5, 2009 [Page 6] Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009 3. Elements of Delay in Video Systems For typical multicast-based video delivery systems, the multicast switching delay (time required to leave the previous multicast session and join the new session) is not the primary contributor to the overall synchronization delay. The multicast flows are typically already present at the edge or deep in the network, the propagation delays for join operations are modest, and the multicast routers can typically process the Join and Leave messages quickly. Even if the edge multicast router is not currently a member of the requested multicast session, the multicast routing control messages propagate through the network rapidly and trees are built without experiencing large delays. Even in cases where a number of tree branches need to be built to the edge multicast router, this cost is frequently amortized over a large number of receivers such that only the first receiver joining the group experiences the increased delay. Further, this delay can be eliminated at the cost of extra bandwidth in the network core by having the edge routers do static joins for the set of sessions they expect receivers to be interested in. These techniques usually provide a well-bounded multicast switching delay. Once the join operation completes and a receiver starts receiving media content for the first time in a multicast session, it often experiences a considerable amount of key information latency and buffering delays. In the following subsections, we discuss the details of these delay elements using MPEG2-TS as the motivating use case. 3.1. Overview of MPEG-2 Transport Streams MPEG2-TS is a container format that describes the schema of the audio and video content and the in-band control information. Prior to multiplexing, an audio and a video encoder output audio and video Elementary Streams (ES), respectively. The ES streams are then packetized to form the Packetized Elementary Streams (PES). The resulting elements are called PES packets. A transport stream (TS) encapsulates several PES streams and other data, and carries them in TS packets. The RTP payload format for carrying TS packets in an RTP stream is specified in [RFC2250]. In addition to the audio and video ES streams, there are ES streams that carry control data. Program Specific Information (PSI) consists of metadata carried in the transport stream. PSI includes Program Association Table (PAT), Conditional Access Table (CAT) and Program Map Table (PMT). A PAT has information about all the programs carried in the transport stream. It lists the 13-bit Program IDs (PID) for all the PMTs, associating them with the individual programs. Each of the ES streams of a particular program in the transport stream also has the Begen Expires September 5, 2009 [Page 7] Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009 same PID values. This way, a decoder at the receiving side can extract the desired TS packets from the transport stream by checking their PID values. If the transport stream is not a Multi-Program Transport Stream (MPTS), but rather it is a Single-Program Transport Stream (SPTS), all the ES streams in the transport stream correspond to a single program. CAT defines the type of the scrambling used (either at the PES or TS level), and identifies all the PID values of the TS packets that contain the Entitlement Management Messages (EMM). In addition to containing the PID values of each ES stream associated with a particular program, the PMT table also includes private data associated with the program such as the PID value of the packet containing the Entitlement Control Messages (ECM). The data contained in the EMM and ECM messages are vital in descrambling encrypted content. Note that PSI is carried in clear and is never scrambled so that a receiver which just started receiving the transport stream can process the PSI. The PAT, CAT and PMT tables must be parsed by the decoder in order to find the ES streams, private data as well as the encryption information for a given program. MPEG2-TS produces output that is synchronized to a common clock across all the ESs in the multiplex. To assist the audio and video decoders, programs periodically provide a Program Clock Reference (PCR) value in the transport stream. PCR values are embedded in the TS adaptation field headers and are inserted by the encoder at least every 100 ms. A PCR timestamp represents the value of the encoder's system clock when it was sampled. The system clock is driven by a local 27 MHz oscillator. PCR is extremely important in native MPEG-2 transport to keep the decoders synchronized. For example, the periodically sent Decoding Timestamps (DTS) and Presentation Timestamps (PTS) are specified relative to the PCR value and the decoders use the PCR value as the basis for a master clock during decoding and playout. 3.2. Key Information Latency in Video Applications We classify the key information latency into two categories. 3.2.1. PSI (PAT/CAT/PMT) Acquisition Delay As we discussed in Section 3.1, the video (and the audio as well) in an MPEG2-TS is self describing, and the receiver must parse certain control information in the PAT, CAT and PMT tables (i.e., PSI) contained in the transport stream in order to know how to parse the rest of the stream (i.e., to find the audio and video elementary Begen Expires September 5, 2009 [Page 8] Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009 streams, private data and the encryption information for a given program). Many video services employ content encryption and the encryption keys must be parsed as well for decrypting the content. In order to enable various system elements to process video effectively, certain portions of the stream are left unencrypted. The PAT/PMT tables are always in the clear. The structure of the ECMs is also in the clear, although the ECM content which contains keying material is encrypted. The PSI information is repeated periodically in the transport stream, thus, when a receiver joins the multicast session, it needs to wait until the next time PSI is sent in the transport stream. 3.2.2. Random Access Point Acquisition Delay Conventional MPEG2 video encoders encode the video content in Groups of Pictures (GoP). Each GoP is encoded independently from other GoPs and starts with an intra-coded frame (I-frame) that does not have any reference to other frames in the same GoP, i.e., an I-frame contains the representation of an entire picture and can be decoded independently. Thus, the start of an I-frame is said to be a Random Access Point (RAP). On the other hand, due to the temporal compression, rest of the frames in the same GoP may have references to the I-frame or to other frames in the same GoP. Due to this interdependency among the frames, one generally has to receive certain elements of the GoP prior to decoding or rendering any part of the GoP. For example, the decoder can decode a frame that is dependent on two other frames only after these two frames are decoded. Usually, GoP durations are between 500 ms and one second. However, more advanced codecs may use longer GoPs to gain from the encoding efficiency. When a receiver joins the multicast session, it needs to wait until the next RAP shows up in the multicast stream before it can start decoding. Since the frame that is currently being multicast does not depend on the join time, the average time a receiver waits for RAP, i.e., the average RAP acquisition delay, is approximately equal to half of the GoP duration. Hence, for longer GoPs, the RAP acquisition delay is proportionally longer. Advanced Video Coding (AVC) (also called MPEG4 part 10) compression is very similar to MPEG2 compression. It has a few more compression tools available, including Hierarchical GoPs. In a hierarchical GoP, the dependent frames of a GoP may reference the key frame at the start of this GoP or the key frame at the start of the next GoP. This additional dependency causes a longer RAP acquisition delay, as the decoder must receive two I-frames (spread between two logical Begen Expires September 5, 2009 [Page 9] Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009 GoPs) before decoding can commence. In an Open GOP, a frame in one GoP may refer to a frame in a previous GoP. AVC also has the ability to insert Instantaneous Decoding Refresh (IDR) frames. Frames that follow an IDR frame cannot reference frames that precede an IDR frame. IDR frames are useful for editing AVC streams, but are typically do not appear often enough in streaming video to be useful in a stream synchronization context. Note that in order for an intermediary network element such as a retransmission server to find the random access points in the video stream (e.g., I-frames), the necessary structural information must be in the clear if the intermediary is not in possession of the necessary keys. 3.3. Buffering Delays in Video Applications We classify the buffering delays into two categories. 3.3.1. Network-Related Buffering Delays In general, multicast-based video applications use an unreliable underlying transport protocol such as UDP [RFC0768] to distribute the content to a large number of receivers. This is largely due to the fact that these applications are one way in nature and providing closed-loop reliability does not scale well when the number of receivers is large or the acceptable playout delay is small, or both. Rather, if there is a need for reliability, the applications may employ one or more loss-repair methods to recover the packets missing at each receiver (The Reliable Multicast Transport Working Group has several standardized solutions for this problem. Refer to [I-D.ietf-rmt-pi-norm-revised] for details). For example, Forward Error Correction (FEC) may be used proactively and/or on-demand to provide reliable transmission to a potentially very large multicast group in a scalable manner [I-D.ietf-fecframe-framework]. Similarly, retransmissions may be used in RTP-based multicast sessions where the retransmissions can be handled by local repair servers rather than the source itself [I-D.ietf-avt-rtcpssm]. However, regardless of the type of the loss-repair method(s) adopted by an application, loss- recovery operations always require additional buffering at the receiver side. The amount of buffering increases with the FEC block size when FEC is used, and with the round-trip time between the receiver and the local repair server when retransmission is used. Audio and video decoders demand almost jitter-free content. If any jitter is introduced during the transmission in the network or due to the loss-repair methods, the jitter has to be smoothed out before the content is fed to the decoder. This is called de-jittering and it usually adds up to the buffering delay. Begen Expires September 5, 2009 [Page 10] Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009 3.3.2. Application-Related Buffering Delays The application buffering requirements for MPEG-encoded content are quite rigorous, particularly for the MPEG-based video applications. Video compression devices apply more bits to represent certain scenes than they do for other scenes. A very complex scene (individual picture) requires considerably more information than a simple scene. Furthermore, pictures that are entirely intra-coded, e.g., I-frames, consume more bits compared to pictures that make use of predictive coding. Each scene is shown by the decoder at a certain fixed frame rate (e.g., 24 fps or 30 fps). Since some scenes are comprised more bits than other scenes, the output rate of the decoder buffer is usually variable. However, the network flow is typically Constant Bit Rate (CBR) or Capped Variable Bit Rate (Capped VBR). The net effect is that the input rate to the decoder buffer is close to constant, but the output rate is highly variable. The video encoders keep track of the decoder buffer size, and use this information to regulate the temporal compression. This forces the decoder buffer to "breathe." In order to avoid underflow, the decoder buffer must fill up to a certain level prior to starting to decode and play the content. The decoder buffer size required to avoid underflow is dependent on the encoder, and the encoder signals the decoder buffering requirements in-band. Typical decoder buffer requirements for MPEG2 content range from a few hundreds of milliseconds to a few seconds. However, AVC/MPEG4 part 10 encoders usually tend to use more temporal compression, and thus require a larger buffer at the decoder side. This consequently increases the buffering delays. Begen Expires September 5, 2009 [Page 11] Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009 4. Packet Format This section defines the MPEG2-TS Preamble packet format. The RTP header is formatted according to [RFC3550] with some further clarifications listed below: o Marker (M) Bit: This bit MAY be used to indicate the last packet carrying the MPEG2-TS Preamble information if there are more than one such packets. Editor's note: This should be discussed. o Payload Type: The (dynamic) payload type for the MPEG2-TS Preamble packets is determined through out-of-band means. Note that this document registers a new payload format for the MPEG2-TS Preamble packets (Refer to Section 5 for details). According to [RFC3550], an RTP receiver that cannot recognize a payload type must discard it. This provides backward compatibility. o Sequence Number (SN): The sequence number has the standard definition. It MUST be one higher than the sequence number in the previously transmitted MPEG2-TS Preamble packet. The initial value of the sequence number SHOULD be random (unpredictable) [RFC3550]. o Timestamp (TS): The timestamp SHALL be set to a time corresponding to the packet's transmission time. o Synchronization Source (SSRC): Per [RFC3550], the SSRC value SHOULD be chosen randomly with collision detection. However, since the RTP session carrying MPEG2-TS Preamble has a short lifetime, using the same SSRC value with the source RTP session carrying the MPEG2-TS may also make sense. Editor's note: This issue should be discussed. The payload has the structure depicted in Figure 1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : TBC : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Format of the MPEG2-TS Preamble payload Begen Expires September 5, 2009 [Page 12] Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009 Editor's note: The format of this message is TBD. Begen Expires September 5, 2009 [Page 13] Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009 5. Payload Format Parameters This section provides the media subtype registration for the MPEG2-TS Preamble. 5.1. Media Type Registration This registration is done using the template defined in [RFC4288] and following the guidance provided in [RFC3555]. 5.1.1. Registration of audio/mpeg2-ts-preamble TBC. 5.1.2. Registration of video/mpeg2-ts-preamble TBC. 5.1.3. Registration of text/mpeg2-ts-preamble TBC. 5.1.4. Registration of application/mpeg2-ts-preamble TBC. 5.2. Mapping to SDP Parameters Applications that are using RTP transport commonly use Session Description Protocol (SDP) [RFC4566] to describe their RTP sessions. The information that is used to specify the media types in an RTP session has specific mappings to the fields in an SDP description. In this section, we provide these mappings for the media subtype registered by this document ("mpeg2-ts-preamble"). Note that if an application does not use SDP to describe the RTP sessions, an appropriate mapping must be defined and used to specify the media types and their parameters for the control/description protocol employed by the application. The mapping of the media type specification for "mpeg2-ts-preamble" and its parameters in SDP is as follows: o The media type (e.g., "application") goes into the "m=" line as the media name. o The media subtype ("mpeg2-ts-preamble") goes into the "a=rtpmap" line as the encoding name. The RTP clock rate parameter ("rate") also goes into the "a=rtpmap" line as the clock rate. Begen Expires September 5, 2009 [Page 14] Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009 o The remaining required payload-format-specific parameters go into the "a=fmtp" line by copying them directly from the media type string as a semicolon-separated list of parameter=value pairs. SDP examples are provided in Section 6. 5.2.1. Offer-Answer Model Considerations TBC. 5.2.2. Declarative Considerations TBC. Begen Expires September 5, 2009 [Page 15] Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009 6. Session Description Protocol (SDP) Signaling This section provides an SDP [RFC4566] example. TBC. Begen Expires September 5, 2009 [Page 16] Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009 7. Security Considerations TBC. Begen Expires September 5, 2009 [Page 17] Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009 8. IANA Considerations New media subtypes are subject to IANA registration. For the registration of the payload format and its parameters introduced in this document, refer to Section 5. Begen Expires September 5, 2009 [Page 18] Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009 9. Acknowledgments TBC. Begen Expires September 5, 2009 [Page 19] Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003. 10.2. Informative References [MPEG2TS] ITU-T H.222.0, "Generic Coding of Moving Pictures and Associated Audio Information: Systems", May 2006. [I-D.versteeg-avt-rapid-synchronization-for-rtp] Steeg, B., Begen, A., and T. Caenegem, "Unicast-Based Rapid Synchronization with RTP Multicast Sessions", draft-versteeg-avt-rapid-synchronization-for-rtp-01 (work in progress), November 2008. [RFC2250] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998. [I-D.ietf-avt-rtcpssm] Ott, J., "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback", draft-ietf-avt-rtcpssm-17 (work in progress), January 2008. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [I-D.ietf-rmt-pi-norm-revised] Adamson, B., Bormann, C., London, U., and J. Macker, "NACK-Oriented Reliable Multicast Protocol", draft-ietf-rmt-pi-norm-revised-08 (work in progress), December 2008. Begen Expires September 5, 2009 [Page 20] Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009 [I-D.ietf-fecframe-framework] Watson, M., "Forward Error Correction (FEC) Framework", draft-ietf-fecframe-framework-03 (work in progress), October 2008. Begen Expires September 5, 2009 [Page 21] Internet-Draft RTP Payload Format for MPEG2-TS Preamble March 2009 Author's Address Ali Begen Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA Email: abegen@cisco.com Begen Expires September 5, 2009 [Page 22]