Skip to main content

Session Description Protocol (SDP) WebSocket Connection URI Attribute
draft-ietf-bfcpbis-sdp-ws-uri-04

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8124.
Authors Ram R , Gonzalo Salgueiro
Last updated 2016-07-19 (Latest revision 2016-05-31)
Replaces draft-ram-bfcpbis-sdp-ws-uri
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Consensus: Waiting for Write-Up
Document shepherd Charles Eckel
IESG IESG state Became RFC 8124 (Proposed Standard)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD (None)
Send notices to "Charles Eckel" <eckelcu@cisco.com>
draft-ietf-bfcpbis-sdp-ws-uri-04
BFCPBIS Working Group                                  Ram. Ravindranath
Internet-Draft                                              G. Salgueiro
Intended status: Standards Track                                   Cisco
Expires: December 2, 2016                                   May 31, 2016

 Session Description Protocol (SDP) WebSocket Connection URI Attribute
                    draft-ietf-bfcpbis-sdp-ws-uri-04

Abstract

   The WebSocket protocol enables bidirectional real-time communication
   between clients and servers in web-based applications.  This document
   specifies extensions to Session Description Protocol (SDP) for
   application protocols using WebSocket as a transport.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on December 2, 2016.

Copyright Notice

   Copyright (c) 2016 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.

Ravindranath & SalgueiroExpires December 2, 2016                [Page 1]
Internet-Draft           WebSocket SDP Attribute                May 2016

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  SDP Considerations  . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  ws-uri SDP Attribute  . . . . . . . . . . . . . . . . . .   3
     3.3.  wss-uri SDP Attribute . . . . . . . . . . . . . . . . . .   4
     3.4.  ws-uri and wss-uri Multiplexing Considerations  . . . . .   4
   4.  SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . .   5
     4.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Generating the Initial Offer  . . . . . . . . . . . . . .   5
     4.3.  Generating the Answer . . . . . . . . . . . . . . . . . .   6
     4.4.  Offerer Processing of the Answer  . . . . . . . . . . . .   7
     4.5.  Modifying the Session . . . . . . . . . . . . . . . . . .   7
     4.6.  Offerless INVITE Scenarios  . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Registration of the 'ws-uri' SDP Media Attribute  . . . .   8
     6.2.  Registration of the 'wss-uri' SDP Media Attribute . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   The WebSocket protocol [RFC6455] enables bidirectional message
   exchange between clients and servers on top of a persistent TCP
   connection (optionally secured with Transport Layer Security (TLS)
   [RFC5246]).  The initial protocol handshake makes use of Hypertext
   Transfer Protocol (HTTP) [RFC7230] semantics, allowing the WebSocket
   protocol to reuse existing HTTP infrastructure.

   Modern web browsers include a WebSocket client stack compliant with
   the WebSocket API [WS-API] as specified by the W3C.  It is expected
   that other client applications (e.g., those running on personal
   computers, mobile devices, etc.) will also make a WebSocket client
   stack available.  Several specifications have been written that
   define how different applications can use a WebSocket subprotocol as
   a reliable transport mechanism.

   For example, [RFC7118] defines WebSocket subprotocol as a reliable
   transport mechanism between Session Initiation Protocol
   (SIP)[RFC3261] entities to enable use of SIP in web-oriented
   deployments.  Additionally, [I-D.pd-dispatch-msrp-websocket] defines
   a new WebSocket sub-protocol as a reliable transport mechanism

Ravindranath & SalgueiroExpires December 2, 2016                [Page 2]
Internet-Draft           WebSocket SDP Attribute                May 2016

   between Message Session Relay Protocol (MSRP) clients and relays.
   [RFC7395] defines a WebSocket subprotocol for the Extensible
   Messaging and Presence Protocol (XMPP).  Similarly,
   [I-D.ietf-bfcpbis-bfcp-websocket] defines a WebSocket sub-protocol as
   a reliable transport mechanism between Binary Floor Control Protocol
   (BFCP) [I-D.ietf-bfcpbis-rfc4582bis] entities to enable usage of BFCP
   in new scenarios.

   As defined in Section 3 of [RFC2818], when using Secure WebSockets
   the Canonical Name (CNAME) of the Secure Sockets Layer (SSL)
   [RFC6101] certificate MUST match the WebSocket connection URI host.
   While it is possible to generate self-signed certificates with
   Internet Providers (IPs) as CNAME, in most cases it is not viable for
   certificates signed by well known authorities.  Thus, there is a need
   to indicate the connection URI for the WebSocket Client.  For
   applications that use Session Description Protocol (SDP) [RFC4566] to
   negotiate, the connection URI can be indicated by means of an SDP
   attribute.  This specification defines new SDP attributes to indicate
   the connection URI for the WebSocket client.  Applications that use
   SDP for negotiation and WebSocket as a transport protocol can use
   this specification to advertise the WebSocket client connection URI.

2.  Terminology

   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].

3.  SDP Considerations

3.1.  General

   Applications that use the SDP Offer/Answer mechanism [RFC3264] for
   negotiating media and also use WebSocket as a transport protocol MAY
   indicate the connection URI for the WebSocket Client via a new SDP a=
   media-level attribute defined in Section 3.2.

   Applications that use SDP for negotiation and also use secure
   WebSocket as a transport protocol TLS MAY indicate the connection URI
   for the WebSocket Client via a new SDP a= media-level attribute
   defined in Section 3.3.

3.2.  ws-uri SDP Attribute

   This section defines a new SDP media-level attribute, 'ws-uri' which
   can appear in any of the media sections.

Ravindranath & SalgueiroExpires December 2, 2016                [Page 3]
Internet-Draft           WebSocket SDP Attribute                May 2016

   Example:

      a=ws-uri:ws://example.com/chat

   Where "ws://example.com/chat" is the ws-URI defined in Section 3 of
   [RFC6455].

   When the 'ws-uri' attribute is present in the media section of the
   SDP, the IP address in 'c= ' line SHALL be ignored and the full URI
   SHALL be used instead to open the WebSocket connection.  The port
   provided in the 'm= ' line SHALL be ignored too, as the 'a=ws-uri'
   SHALL provide port number when needed.

3.3.  wss-uri SDP Attribute

   This section defines a new SDP media-level attribute, 'wss-uri' which
   can appear in any of the media sections.

   Example:

      a=wss-uri:wss://example.com/chat

   Here "wss://example.com/chat" is the wss-URI defined in Section 3 of
   [RFC6455].

   When the 'wss-uri' attribute is present in the media section of the
   SDP, the IP address in 'c= ' line SHALL be ignored and the full URI
   SHALL be used instead to open the secure WebSocket connection.  The
   port provided in the 'm= ' line SHALL be ignored too, as the 'a=wss-
   uri' SHALL provide port number when needed.

3.4.  ws-uri and wss-uri Multiplexing Considerations

   Multiplexing characteristics of SDP attributes are described in
   [I-D.ietf-mmusic-sdp-mux-attributes].  Various SDP attribute
   multiplexing categories are introduced there.

   o  The multiplexing category of the "a=ws-uri:" attribute is NOT
      RECOMMENDED.

   o  The multiplexing category of the "a=wss-uri:" attribute is NOT
      RECOMMENDED.

   There are no multiplexing rules specified for the ws-uri and wss-uri
   SDP media-level attributes.  Additionally, the specification of
   multiplexing rules for the ws-uri and wss-uri attributes is outside
   the scope of this document.

Ravindranath & SalgueiroExpires December 2, 2016                [Page 4]
Internet-Draft           WebSocket SDP Attribute                May 2016

   While it is technically possible to bundle WebSocket, there are a
   variety of reasons that make it impractical and it is thus considered
   unlikely to be used in practice.  Therefore, the ws-uri and wss-uri
   SDP media-level attributes defined in Section 3.2 and Section 3.3 for
   using WebSocket as a transport protocol are not likely to be used
   with SDP bundle and are consequently categorized as NOT RECOMMENDED
   for multiplexing.

   If future extensions define how to bundle WebSocket then multiplexing
   rules for the "a=ws-uri:" and "a=wss-uri:" attributes need to be
   defined as well, for instance in an extension of this SDP based
   WebSocket negotiation specification.

4.  SDP Offer/Answer Procedures

4.1.  General

   An endpoint (i.e., both the offerer and the answerer) that wishes to
   negotiate WebSocket as transport protocol MUST indicate that it
   wishes to use WebSocket or secure WebSocket in the "proto" field of
   the "m=" line.  Furthermore, the server side, which could be either
   the offerer or answerer, MUST add an "a=ws-uri" or "a=wss-uri"
   attribute in the media section depending on whether it wishes to use
   WebSocket or secure WebSocket.  This new attribute MUST follow the
   syntax defined in Section 3.  The procedures in this section apply to
   an "m=" line associated with any media stream that uses WebSocket or
   secure WebSocket as transport.

4.2.  Generating the Initial Offer

   An SDP offerer in order to negotiate WebSocket as a transport MUST
   indicate the same in the "proto" field of the "m=" line.  For
   example, to negotiate BFCP-over-WebSocket the "proto" value in the
   "m=" line MUST be TCP/WSS/BFCP if WebSocket is over TLS, else it MUST
   be TCP/WS/BFCP.

   The offerer SHOULD assign the SDP "setup" attribute with a value of
   "active" (the offerer will be the initiator of the outgoing TCP
   connection), unless the offerer insists on being a receiver of an
   incoming connection, in which case the offerer SHOULD use a value of
   "passive".  The offerer MUST NOT assign an SDP "setup" attribute with
   a "holdconn" value.  If the offerer assigns the SDP "setup" attribute
   with a value of "passive", the offerer MUST be prepared to receive an
   incoming TCP connection on the IP and port tuple advertised in the
   "c=" line and audio/video ports of the BFCP media stream before it
   receives the SDP answer.

   The following is an example of an "m=" line for a BFCP connection:

Ravindranath & SalgueiroExpires December 2, 2016                [Page 5]
Internet-Draft           WebSocket SDP Attribute                May 2016

   Offer (browser):
   m=application 9 TCP/WSS/BFCP *
   a=setup:active
   a=connection:new
   a=floorctrl:c-only
   m=audio 55000 RTP/AVP 0
   m=video 55002 RTP/AVP 31

   In the above example, the client is intending to setup the TLS /TCP
   connection and hence the port is set to a value of 9, which is the
   discard port.

4.3.  Generating the Answer

   If the answerer accepts the offered WebSocket transport connection,
   in the associated SDP answer, the answerer MUST assign an SDP "setup"
   attribute with a value of either "active" or "passive", according to
   the procedures in [RFC4145].  The answerer MUST NOT assign an SDP
   "setup" attribute with a value of "holdconn".

   If the answerer assigns an SDP "setup" attribute with a value of
   "active", the answerer MUST initiate the WebSocket connection
   handshake by acting as client on the negotiated media stream, towards
   the IP address and port of the offerer using the procedures described
   in [RFC6455].  The answer MUST have an "a=ws-uri" or "a=wss-uri"
   attribute depending on whether the application uses WebSocket or
   secureWebSocket.  This attribute MUST follow the syntax defined in
   Section 3.  For BFCP application, the "proto" value in the "m=" line
   MUST be TCP/WSS/BFCP if WebSocket is run on TLS, else it MUST be
   TCP/WS/BFCP.

   The following example shows a case where the server responds with a
   BFCP media stream over a WebSocket connection running TLS.  It shows
   an answer "m=" line for the BFCP connection.  In this example since
   WebSockets is running over TLS, the server answers back with "a=wss-
   uri" attribute in the media section of SDP indicating the connection
   URI:

Ravindranath & SalgueiroExpires December 2, 2016                [Page 6]
Internet-Draft           WebSocket SDP Attribute                May 2016

   Answer (server):
   m=application 50000 TCP/WSS/BFCP *
   a=setup:passive
   a=connection:new
   a=wss-uri:wss://bfcp-ws.example.com?token=3170449312
   a=floorctrl:s-only
   a=confid:4321
   a=userid:1234
   a=floorid:1 m-stream:10
   a=floorid:2 m-stream:11
   m=audio 50002 RTP/AVP 0
   a=label:10
   m=video 50004 RTP/AVP 31
   a=label:11

4.4.  Offerer Processing of the Answer

   When the offerer receives an SDP answer, if the offerer ends up being
   active it MUST initiate the WebSocket connection handshake by sending
   a GET message on the negotiated media stream, towards the IP address
   and port of the answerer, as per the procedures described in
   [RFC6455].

4.5.  Modifying the Session

   Once an offer/answer exchange has been completed, either endpoint MAY
   send a new offer in order to modify the session.  The endpoints can
   reuse the existing WebSocket connection by adding
   "a=connection:existing" attribute in the media section of SDP
   following the rules mentioned in [RFC4145] if the ws-uri values and
   the transport parameters indicated by each endpoint are unchanged.
   Otherwise, following the rules for the initial offer/answer exchange,
   the endpoints can negotiate and create a new WebSocket connection on
   top of TLS/TCP or TCP.

4.6.  Offerless INVITE Scenarios

   In some scenarios an endpoint (e.g., a browser) originating the call
   (UAC) can send an offerless INVITE to the server.  The server will
   generate an offer in response to the INVITE.  In such cases the
   server MUST send an offer with setup attribute as "passive" so as to
   accept incoming connection and MUST include "a=wss-uri" or "a=ws-uri"
   attribute in the media section depending on whether the server wishes
   to use WebSocket or secure WebSocket.  The SDP offer sent by the
   server will look like the example in Section 4.3.

Ravindranath & SalgueiroExpires December 2, 2016                [Page 7]
Internet-Draft           WebSocket SDP Attribute                May 2016

5.  Security Considerations

   An attacker may attempt to add, modify, or remove 'a=ws-uri' or
   'a=wss-uri' attribute from a session description.  This could result
   in an application behaving undesirably.  Consequently, it is strongly
   RECOMMENDED that integrity protection be applied to the SDP session
   descriptions.  For session descriptions carried in SIP [RFC3261], S/
   MIME is the natural choice to provide such end-to-end integrity
   protection.

   It is also RECOMMENDED that the application signaling traffic being
   transported over a WebSocket communication session be protected by
   using a secure WebSocket connection (using TLS [RFC5246] over TCP).

6.  IANA Considerations

6.1.  Registration of the 'ws-uri' SDP Media Attribute

   NOTE to RFC Editor: Please replace "XXXX" with the number of this
   RFC.

   This document defines a new SDP media-level attribute "ws-uri" in
   Section 3.2 and requests that IANA to register the following SDP att-
   field under the Session Description Protocol (SDP) Parameters
   registry as follows:

   +---------------------+---------------------------------------------+
   | Attribute name:     | ws-uri                                      |
   | Long-form attribute | Websocket Connection URI                    |
   | name:               |                                             |
   | Type of attribute:  | media                                       |
   | Mux category:       | NOT RECOMMENDED                             |
   | Charset Dependent:  | No                                          |
   | Purpose:            | The 'ws-uri' attribute is intended to be    |
   |                     | used as a connection URI for opening the    |
   |                     | WebSocket connection.                       |
   | Appropriate values: | A ws-URI as defined in [RFC6455]            |
   | Contact name:       | Gonzalo Salgueiro                           |
   | Contact e-mail:     | gsalguei@cisco.com                          |
   | Reference:          | RFCXXXX                                     |
   +---------------------+---------------------------------------------+

6.2.  Registration of the 'wss-uri' SDP Media Attribute

   NOTE to RFC Editor: Please replace "XXXX" with the number of this
   RFC.

Ravindranath & SalgueiroExpires December 2, 2016                [Page 8]
Internet-Draft           WebSocket SDP Attribute                May 2016

   This document defines a new SDP media-level attribute "wss-uri" in
   Section 3.3 and requests that IANA to register the following SDP att-
   field under the Session Description Protocol (SDP) Parameters
   registry as follows:

   +---------------------+---------------------------------------------+
   | Attribute name:     | wss-uri                                     |
   | Long-form attribute | Websocket Connection URI over Secure        |
   | name:               | Transport                                   |
   | Type of attribute:  | media                                       |
   | Mux category:       | NOT RECOMMENDED                             |
   | Charset Dependent:  | No                                          |
   | Purpose:            | The 'wss-uri' attribute is intended to be   |
   |                     | used as a connection URI for opening the    |
   |                     | WebSocket connection over a secure          |
   |                     | transport.                                  |
   | Appropriate values: | A wss-URI as defined in [RFC6455]           |
   | Contact name:       | Gonzalo Salgueiro                           |
   | Contact e-mail:     | gsalguei@cisco.com                          |
   | Reference:          | RFCXXXX                                     |
   +---------------------+---------------------------------------------+

7.  Acknowledgements

   Thanks to Christer Holmberg for raising the need for a BFCP-
   independent SDP attribute for WebSocket Connection URI.

   The authors wish to acknowledge Paul Kyzivat, Suhas Nandakumar,
   Christer Holmberg and Charles Eckel for their invaluable suggestions
   and review comments.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4145]  Yon, D. and G. Camarillo, "TCP-Based Media Transport in
              the Session Description Protocol (SDP)", RFC 4145,
              DOI 10.17487/RFC4145, September 2005,
              <http://www.rfc-editor.org/info/rfc4145>.

   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
              RFC 6455, DOI 10.17487/RFC6455, December 2011,
              <http://www.rfc-editor.org/info/rfc6455>.

Ravindranath & SalgueiroExpires December 2, 2016                [Page 9]
Internet-Draft           WebSocket SDP Attribute                May 2016

8.2.  Informative References

   [I-D.ietf-bfcpbis-bfcp-websocket]
              Pascual, V., Roman, A., Cazeaux, S., Salgueiro, G., R, R.,
              and S. Murillo, "The WebSocket Protocol as a Transport for
              the Binary Floor Control Protocol (BFCP)", draft-ietf-
              bfcpbis-bfcp-websocket-07 (work in progress), May 2016.

   [I-D.ietf-bfcpbis-rfc4582bis]
              Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C.
              Eckel, "The Binary Floor Control Protocol (BFCP)", draft-
              ietf-bfcpbis-rfc4582bis-16 (work in progress), November
              2015.

   [I-D.ietf-mmusic-sdp-mux-attributes]
              Nandakumar, S., "A Framework for SDP Attributes when
              Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12
              (work in progress), January 2016.

   [I-D.pd-dispatch-msrp-websocket]
              Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G.,
              and R. R, "The WebSocket Protocol as a Transport for the
              Message Session Relay Protocol (MSRP)", draft-pd-dispatch-
              msrp-websocket-12 (work in progress), May 2016.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
              DOI 10.17487/RFC2818, May 2000,
              <http://www.rfc-editor.org/info/rfc2818>.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <http://www.rfc-editor.org/info/rfc3261>.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              DOI 10.17487/RFC3264, June 2002,
              <http://www.rfc-editor.org/info/rfc3264>.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
              July 2006, <http://www.rfc-editor.org/info/rfc4566>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

Ravindranath & SalgueiroExpires December 2, 2016               [Page 10]
Internet-Draft           WebSocket SDP Attribute                May 2016

   [RFC6101]  Freier, A., Karlton, P., and P. Kocher, "The Secure
              Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
              DOI 10.17487/RFC6101, August 2011,
              <http://www.rfc-editor.org/info/rfc6101>.

   [RFC7118]  Baz Castillo, I., Millan Villegas, J., and V. Pascual,
              "The WebSocket Protocol as a Transport for the Session
              Initiation Protocol (SIP)", RFC 7118,
              DOI 10.17487/RFC7118, January 2014,
              <http://www.rfc-editor.org/info/rfc7118>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

   [RFC7395]  Stout, L., Ed., Moffitt, J., and E. Cestari, "An
              Extensible Messaging and Presence Protocol (XMPP)
              Subprotocol for WebSocket", RFC 7395,
              DOI 10.17487/RFC7395, October 2014,
              <http://www.rfc-editor.org/info/rfc7395>.

   [WS-API]   W3C and I. Hickson, Ed., "The WebSocket API", May 2012.

Authors' Addresses

   Ram Mohan Ravindranath
   Cisco Systems, Inc.
   Cessna Business Park,
   Kadabeesanahalli Village, Varthur Hobli,
   Sarjapur-Marathahalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: rmohanr@cisco.com

   Gonzalo Salgueiro
   Cisco Systems, Inc.
   7200-12 Kit Creek Road
   Research Triangle Park, NC  27709
   US

   Email: gsalguei@cisco.com

Ravindranath & SalgueiroExpires December 2, 2016               [Page 11]