idnits 2.17.1 draft-ietf-avtext-framemarking-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (July 3, 2017) is 2482 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-payload-vp9-03 -- Obsolete informational reference (is this intentional?): RFC 5285 (Obsoleted by RFC 8285) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Berger 3 Internet-Draft S. Nandakumar 4 Intended status: Standards Track M. Zanaty 5 Expires: January 4, 2018 Cisco Systems 6 July 3, 2017 8 Frame Marking RTP Header Extension 9 draft-ietf-avtext-framemarking-05 11 Abstract 13 This document describes a Frame Marking RTP header extension used to 14 convey information about video frames that is critical for error 15 recovery and packet forwarding in RTP middleboxes or network nodes. 16 It is most useful when media is encrypted, and essential when the 17 middlebox or node has no access to the media decryption keys. It is 18 also useful for codec-agnostic processing of encrypted or unencrypted 19 media, while it also supports extensions for codec-specific 20 information. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 4, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Key Words for Normative Requirements . . . . . . . . . . . . 4 58 3. Frame Marking RTP Header Extension . . . . . . . . . . . . . 4 59 3.1. Extension for Non-Scalable Streams . . . . . . . . . . . 4 60 3.2. Extension for Scalable Streams . . . . . . . . . . . . . 5 61 3.2.1. Layer ID Mappings for Scalable Streams . . . . . . . 6 62 3.2.1.1. H265 LID Mapping . . . . . . . . . . . . . . . . 6 63 3.2.1.2. H264-SVC LID Mapping . . . . . . . . . . . . . . 7 64 3.2.1.3. H264 (AVC) LID Mapping . . . . . . . . . . . . . 7 65 3.2.1.4. VP8 LID Mapping . . . . . . . . . . . . . . . . . 7 66 3.2.1.5. Future Codec LID Mapping . . . . . . . . . . . . 7 67 3.3. Signaling Information . . . . . . . . . . . . . . . . . . 8 68 3.4. Usage Considerations . . . . . . . . . . . . . . . . . . 8 69 3.4.1. Relation to Layer Refresh Request (LRR) . . . . . . . 8 70 3.4.2. Complex or Irregular Scalability Structures . . . . . 8 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 76 7.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 Many widely deployed RTP [RFC3550] topologies [RFC7667] used in 82 modern voice and video conferencing systems include a centralized 83 component that acts as an RTP switch. It receives voice and video 84 streams from each participant, which may be encrypted using SRTP 85 [RFC3711], or extensions that provide participants with private media 86 via end-to-end encryption where the switch has no access to media 87 decryption keys. The goal is to provide a set of streams back to the 88 participants which enable them to render the right media content. In 89 a simple video configuration, for example, the goal will be that each 90 participant sees and hears just the active speaker. In that case, 91 the goal of the switch is to receive the voice and video streams from 92 each participant, determine the active speaker based on energy in the 93 voice packets, possibly using the client-to-mixer audio level RTP 94 header extension [RFC6464], and select the corresponding video stream 95 for transmission to participants; see Figure 1. 97 In this document, an "RTP switch" is used as a common short term for 98 the terms "switching RTP mixer", "source projecting middlebox", 99 "source forwarding unit/middlebox" and "video switching MCU" as 100 discussed in [RFC7667]. 102 +---+ +------------+ +---+ 103 | A |<---->| |<---->| B | 104 +---+ | | +---+ 105 | RTP | 106 +---+ | Switch | +---+ 107 | C |<---->| |<---->| D | 108 +---+ +------------+ +---+ 110 Figure 1: RTP switch 112 In order to properly support switching of video streams, the RTP 113 switch typically needs some critical information about video frames 114 in order to start and stop forwarding streams. 116 o Because of inter-frame dependencies, it should ideally switch 117 video streams at a point where the first frame from the new 118 speaker can be decoded by recipients without prior frames, e.g 119 switch on an intra-frame. 120 o In many cases, the switch may need to drop frames in order to 121 realize congestion control techniques, and needs to know which 122 frames can be dropped with minimal impact to video quality. 123 o Furthermore, it is highly desirable to do this in a payload 124 format-agnostic way which is not specific to each different video 125 codec. Most modern video codecs share common concepts around 126 frame types and other critical information to make this codec- 127 agnostic handling possible. 128 o It is also desirable to be able to do this for SRTP without 129 requiring the video switch to decrypt the packets. SRTP will 130 encrypt the RTP payload format contents and consequently this data 131 is not usable for the switching function without decryption, which 132 may not even be possible in the case of end-to-end encryption of 133 private media. 135 By providing meta-information about the RTP streams outside the 136 encrypted media payload, an RTP switch can do codec-agnostic 137 selective forwarding without decrypting the payload. This document 138 specifies the necessary meta-information in an RTP header extension. 140 2. Key Words for Normative Requirements 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 3. Frame Marking RTP Header Extension 148 This specification uses RTP header extensions as defined in 149 [RFC5285]. A subset of meta-information from the video stream is 150 provided as an RTP header extension to allow an RTP switch to do 151 generic selective forwarding of video streams encoded with 152 potentially different video codecs. 154 The Frame Marking RTP header extension is encoded using the one-byte 155 header or two-byte header as described in [RFC5285]. The one-byte 156 header format is used for examples in this memo. The two-byte header 157 format is used when other two-byte header extensions are present in 158 the same RTP packet, since mixing one-byte and two-byte extensions is 159 not possible in the same RTP packet. 161 This extension is only specified for Source (not Redunadancy) RTP 162 Streams [RFC7656] that carry video payloads. It is not specified for 163 audio payloads, nor is it specified for Redundancy RTP Streams. The 164 (separate) specifications for Redudancy RTP Streams often include 165 provisions for recovering any header extensions that were part of the 166 original source packet. Such provisions SHALL be followed to recover 167 the Frame Marking RTP header extension of the original source packet. 169 3.1. Extension for Non-Scalable Streams 171 The following RTP header extension is RECOMMENDED for non-scalable 172 streams. It MAY also be used for scalable streams if the sender has 173 limited or no information about stream scalability. The ID is 174 assigned per [RFC5285], and the length is encoded as L=0 which 175 indicates 1 octet of data. 177 0 1 178 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | ID=? | L=0 |S|E|I|D|0 0 0 0| 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 The following information are extracted from the media payload and 184 sent in the Frame Marking RTP header extension. 186 o S: Start of Frame (1 bit) - MUST be 1 in the first packet in a 187 frame; otherwise MUST be 0. 188 o E: End of Frame (1 bit) - MUST be 1 in the last packet in a frame; 189 otherwise MUST be 0. 190 o I: Independent Frame (1 bit) - MUST be 1 for frames that can be 191 decoded independent of prior frames, e.g. intra-frame, VPX 192 keyframe, H.264 IDR [RFC6184], H.265 IDR/CRA/BLA/RAP [RFC7798]; 193 otherwise MUST be 0. 194 o D: Discardable Frame (1 bit) - MUST be 1 for frames that can be 195 discarded, and still provide a decodable media stream; otherwise 196 MUST be 0. 197 o The remaining (4 bits) - MUST be 0 for non-scalable streams. 199 3.2. Extension for Scalable Streams 201 The following RTP header extension is RECOMMENDED for scalable 202 streams. It MAY also be used for non-scalable streams, in which case 203 TID, LID and TL0PICIDX MUST be 0. The ID is assigned per [RFC5285], 204 and the length is encoded as L=2 which indicates 3 octets of data. 206 0 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | ID=? | L=2 |S|E|I|D|B| TID | LID | TL0PICIDX | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 The following information are extracted from the media payload and 213 sent in the Frame Marking RTP header extension. 215 o S: Start of Frame (1 bit) - MUST be 1 in the first packet in a 216 frame within a layer; otherwise MUST be 0. 217 o E: End of Frame (1 bit) - MUST be 1 in the last packet in a frame 218 within a layer; otherwise MUST be 0. 219 o I: Independent Frame (1 bit) - MUST be 1 for frames that can be 220 decoded independent of prior frames, e.g. intra-frame, VPX 221 keyframe, H.264 IDR [RFC6184], H.265 IDR/CRA/BLA/RAP [RFC7798]; 222 otherwise MUST be 0. 223 o D: Discardable Frame (1 bit) - MUST be 1 for frames that can be 224 discarded, and still provide a decodable media stream; otherwise 225 MUST be 0. 226 o B: Base Layer Sync (1 bit) - MUST be 1 if this frame only depends 227 on the base layer; otherwise MUST be 0. If no scalability is 228 used, this MUST be 0. 229 o TID: Temporal ID (3 bits) - The base temporal layer starts with 0, 230 and increases with 1 for each higher temporal layer/sub-layer. If 231 no scalability is used, this MUST be 0. 233 o LID: Layer ID (8 bits) - Identifies the spatial and quality layer 234 encoded. If no scalability is used, this MUST be 0 or omitted. 235 When omitted, TL0PICIDX MUST also be omitted. 236 o TL0PICIDX: Temporal Layer 0 Picture Index (8 bits) - Running index 237 of base temporal layer 0 frames when TID is 0. When TID is not 0, 238 this indicates a dependency on the given index. If no scalability 239 is used, this MUST be 0 or omitted. When omitted, LID MUST also 240 be omitted. 242 The layer information contained in TID and LID convey useful aspects 243 of the layer structure that can be utilized in selective forwarding. 244 Without further information about the layer structure, these 245 identifiers can only be used for relative priority of layers. They 246 convey a layer hierarchy with TID=0 and LID=0 identifying the base 247 layer. Higher values of TID identify higher temporal layers with 248 higher frame rates. Higher values of LID identify higher spatial 249 and/or quality layers with higher resolutions and/or bitrates. 251 With further information, for example, possible future RTCP SDES 252 items that convey full layer structure information, it may be 253 possible to map these TIDs and LIDs to specific frame rates, 254 resolutions and bitrates. Such additional layer information may be 255 useful for forwarding decisions in the RTP switch, but is beyond the 256 scope of this memo. The relative layer information is still useful 257 for many selective forwarding decisions even without such additional 258 layer information. 260 3.2.1. Layer ID Mappings for Scalable Streams 262 3.2.1.1. H265 LID Mapping 264 The following shows the H265 [RFC7798] LayerID (6 bits) and TID (3 265 bits) from the NAL unit header mapped to the generic LID and TID 266 fields. 268 The I bit MUST be 1 when the NAL unit type is 16-23 (inclusive), 269 otherwise it MUST be 0. 271 The S and E bits MUST match the corresponding bits in PACI:PHES:TSCI 272 payload structures. 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | ID=2 | L=2 |S|E|I|D|B| TID |0|0| LayerID | TL0PICIDX | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 3.2.1.2. H264-SVC LID Mapping 282 The following shows H264-SVC [RFC6190] Layer encoding information (3 283 bits for spatial/dependency layer, 4 bits for quality layer and 3 284 bits for temporal layer) mapped to the generic LID and TID fields. 286 The S, E, I and D bits MUST match the corresponding bits in PACSI 287 payload structures. 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | ID=2 | L=2 |S|E|I|D|B| TID |0| DID | QID | TL0PICIDX | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 3.2.1.3. H264 (AVC) LID Mapping 297 The following shows the header extension for H264 (AVC) [RFC6184] 298 that contains only temporal layer information. 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | ID=2 | L=2 |S|E|I|D|B| TID |0|0|0|0|0|0|0|0| TL0PICIDX | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 3.2.1.4. VP8 LID Mapping 308 The following shows the header extension for VP8 [RFC7741] that 309 contains only temporal layer information. 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | ID=2 | L=2 |S|E|I|D|B| TID |0|0|0|0|0|0|0|0| TL0PICIDX | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 3.2.1.5. Future Codec LID Mapping 319 The RTP payload format specification for future video codecs SHOULD 320 include a section describing the LID mapping and TID mapping for the 321 codec. For example, the LID/TID mapping for the VP9 codec is 322 described in the VP9 RTP Payload Format [I-D.ietf-payload-vp9]. 324 3.3. Signaling Information 326 The URI for declaring this header extension in an extmap attribute is 327 "urn:ietf:params:rtp-hdrext:framemarking". It does not contain any 328 extension attributes. 330 An example attribute line in SDP: 332 a=extmap:3 urn:ietf:params:rtp-hdrext:framemarking 334 3.4. Usage Considerations 336 The header extension values MUST represent what is already in the RTP 337 payload. 339 When an RTP switch needs to discard a received video frame due to 340 congestion control considerations, it is RECOMMENDED that it 341 preferably drop frames marked with the D (Discardable) bit set, or 342 the highest values of TID and LID, which indicate the highest 343 temporal and spatial/quality enhancement layers, since those 344 typically have fewer dependenices on them than lower layers. 346 When an RTP switch wants to forward a new video stream to a receiver, 347 it is RECOMMENDED to select the new video stream from the first 348 switching point with the I (Independent) bit set and forward the 349 same. An RTP switch can request a media source to generate a 350 switching point by sending Full Intra Request (RTCP FIR) as defined 351 in [RFC5104], for example. 353 3.4.1. Relation to Layer Refresh Request (LRR) 355 Receivers can use the Layer Refresh Request (LRR) 356 [I-D.ietf-avtext-lrr] RTCP feedback message to upgrade to a higher 357 layer in scalable encodings. The TID/LID values and formats used in 358 LRR messages MUST correspond to the same values and formats specified 359 in Section 3.2. 361 3.4.2. Complex or Irregular Scalability Structures 363 The LID and TID information is most useful for simple, regular 364 scalability structures such as hierarchical temporal or spatial/ 365 quality layering structures. The LID and TID information is less 366 useful, or even not useful at all, for complex, irregular scalability 367 structures that do not conform to simple patterns of inter-layer 368 dependencies and referencing structures. Therefore it is NOT 369 RECOMMENDED to use LID and TID information for RTP switch forwarding 370 decisions in the case of complex or irregular scalability structures. 372 4. Security Considerations 374 In the Secure Real-Time Transport Protocol (SRTP) [RFC3711], RTP 375 header extensions are authenticated but usually not encrypted. When 376 header extensions are used some of the payload type information are 377 exposed and visible to middle boxes. The encrypted media data is not 378 exposed, so this is not seen as a high risk exposure. 380 5. Acknowledgements 382 Many thanks to Bernard Aboba, Jonathan Lennox, and Stephan Wenger for 383 their inputs. 385 6. IANA Considerations 387 This document defines a new extension URI to the RTP Compact 388 HeaderExtensions sub-registry of the Real-Time Transport Protocol 389 (RTP) Parameters registry, according to the following data: 391 Extension URI: urn:ietf:params:rtp-hdrext:framemarkinginfo 392 Description: Frame marking information for video streams 393 Contact: mzanaty@cisco.com 394 Reference: RFC XXXX 396 Note to RFC Editor: please replace RFC XXXX with the number of this 397 RFC. 399 7. References 401 7.1. Normative References 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, 405 DOI 10.17487/RFC2119, March 1997, 406 . 408 7.2. Informative References 410 [I-D.ietf-avtext-lrr] 411 Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. 412 Flodman, "The Layer Refresh Request (LRR) RTCP Feedback 413 Message", draft-ietf-avtext-lrr-07 (work in progress), 414 July 2017. 416 [I-D.ietf-payload-vp9] 417 Uberti, J., Holmer, S., Flodman, M., Lennox, J., and D. 418 Hong, "RTP Payload Format for VP9 Video", draft-ietf- 419 payload-vp9-03 (work in progress), March 2017. 421 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 422 Jacobson, "RTP: A Transport Protocol for Real-Time 423 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 424 July 2003, . 426 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 427 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 428 RFC 3711, DOI 10.17487/RFC3711, March 2004, 429 . 431 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 432 "Codec Control Messages in the RTP Audio-Visual Profile 433 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 434 February 2008, . 436 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 437 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 438 2008, . 440 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 441 Payload Format for H.264 Video", RFC 6184, 442 DOI 10.17487/RFC6184, May 2011, 443 . 445 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 446 "RTP Payload Format for Scalable Video Coding", RFC 6190, 447 DOI 10.17487/RFC6190, May 2011, 448 . 450 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 451 Transport Protocol (RTP) Header Extension for Client-to- 452 Mixer Audio Level Indication", RFC 6464, 453 DOI 10.17487/RFC6464, December 2011, 454 . 456 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 457 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 458 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 459 DOI 10.17487/RFC7656, November 2015, 460 . 462 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, 463 DOI 10.17487/RFC7667, November 2015, 464 . 466 [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. 467 Galligan, "RTP Payload Format for VP8 Video", RFC 7741, 468 DOI 10.17487/RFC7741, March 2016, 469 . 471 [RFC7798] Wang, Y., Sanchez, Y., Schierl, T., Wenger, S., and M. 472 Hannuksela, "RTP Payload Format for High Efficiency Video 473 Coding (HEVC)", RFC 7798, DOI 10.17487/RFC7798, March 474 2016, . 476 Authors' Addresses 478 Espen Berger 479 Cisco Systems 481 Phone: +47 98228179 482 Email: espeberg@cisco.com 484 Suhas Nandakumar 485 Cisco Systems 486 170 West Tasman Drive 487 San Jose, CA 95134 488 US 490 Email: snandaku@cisco.com 492 Mo Zanaty 493 Cisco Systems 494 170 West Tasman Drive 495 San Jose, CA 95134 496 US 498 Email: mzanaty@cisco.com