Internet DRAFT - draft-eckel-aeon-use-cases

draft-eckel-aeon-use-cases







Internet Engineering Task Force                                 C. Eckel
Internet-Draft                                                  T. Reddy
Intended status: Informational                       Cisco Systems, Inc.
Expires: August 18, 2014                               February 14, 2014


             Application Enabled Open Networking Use Cases
                     draft-eckel-aeon-use-cases-01

Abstract

   This document describes application enabled open networking use
   cases.  Application enabled open networking (AEON) is a framework in
   which applications explicitly signal their flow characteristics to
   the network.  This provides network nodes with visibility of the
   application flow characteristics, which enables them to apply the
   correct flow treatment and provide feedback to applications.

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 August 18, 2014.

Copyright Notice

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




Eckel & Reddy            Expires August 18, 2014                [Page 1]

Internet-Draft               AEON Use Cases                February 2014


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Home: Consistent experience of video conferencing with
           competing traffic . . . . . . . . . . . . . . . . . . . .   5
       2.1.1.  Description of Problem  . . . . . . . . . . . . . . .   5
       2.1.2.  Proposed Solution . . . . . . . . . . . . . . . . . .   5
       2.1.3.  User Benefit  . . . . . . . . . . . . . . . . . . . .   5
       2.1.4.  Operator Benefit  . . . . . . . . . . . . . . . . . .   5
       2.1.5.  Flow characteristics provided by application  . . . .   6
       2.1.6.  Action taken by network as result of receiving flow
               characteristics . . . . . . . . . . . . . . . . . . .   6
       2.1.7.  Feedback provided by network  . . . . . . . . . . . .   6
       2.1.8.  Security and Privacy Considerations . . . . . . . . .   6
     2.2.  Firewall Traversal: Identification of new applications  .   6
       2.2.1.  Description of Problem  . . . . . . . . . . . . . . .   6
       2.2.2.  Proposed Solution . . . . . . . . . . . . . . . . . .   6
       2.2.3.  User Benefit  . . . . . . . . . . . . . . . . . . . .   7
       2.2.4.  Operator Benefit  . . . . . . . . . . . . . . . . . .   7
       2.2.5.  Flow characteristics provided by application  . . . .   7
       2.2.6.  Action taken by firewall as result of receiving flow
               characteristics . . . . . . . . . . . . . . . . . . .   7
       2.2.7.  Feedback provided by firewall . . . . . . . . . . . .   7
       2.2.8.  Security and Privacy Considerations . . . . . . . . .   7
     2.3.  Load Balancing: Identification of application for better
           load balancing without solely relying on inspection
           techniques  . . . . . . . . . . . . . . . . . . . . . . .   7
       2.3.1.  Description of Problem  . . . . . . . . . . . . . . .   8
       2.3.2.  Proposed Solution . . . . . . . . . . . . . . . . . .   8
       2.3.3.  User Benefit  . . . . . . . . . . . . . . . . . . . .   8
       2.3.4.  Operator Benefit  . . . . . . . . . . . . . . . . . .   8
       2.3.5.  Flow characteristics provided by application  . . . .   8
       2.3.6.  Action taken by network as result of receiving flow
               characteristics . . . . . . . . . . . . . . . . . . .   8
       2.3.7.  Feedback provided by network  . . . . . . . . . . . .   8
       2.3.8.  Security and Privacy Considerations . . . . . . . . .   8
     2.4.  Scavenger class: Creation of a scavenger class. Use
           metadata to shift high-bandwidth, low priority traffic to
           off-peak hours  . . . . . . . . . . . . . . . . . . . . .   8
       2.4.1.  Description of Problem  . . . . . . . . . . . . . . .   8
       2.4.2.  Proposed Solution . . . . . . . . . . . . . . . . . .   8
       2.4.3.  User Benefit  . . . . . . . . . . . . . . . . . . . .   8
       2.4.4.  Operator Benefit  . . . . . . . . . . . . . . . . . .   8
       2.4.5.  Flow characteristics provided by application  . . . .   8



Eckel & Reddy            Expires August 18, 2014                [Page 2]

Internet-Draft               AEON Use Cases                February 2014


       2.4.6.  Action taken by network as result of receiving flow
               characteristics . . . . . . . . . . . . . . . . . . .   8
       2.4.7.  Feedback provided by network  . . . . . . . . . . . .   8
       2.4.8.  Security and Privacy Considerations . . . . . . . . .   8
     2.5.  Video Adaptation: Use client metadata to help video bit
           rate selection  . . . . . . . . . . . . . . . . . . . . .   8
       2.5.1.  Description of Problem  . . . . . . . . . . . . . . .   9
       2.5.2.  Proposed Solution . . . . . . . . . . . . . . . . . .   9
       2.5.3.  User Benefit  . . . . . . . . . . . . . . . . . . . .  10
       2.5.4.  Operator Benefit  . . . . . . . . . . . . . . . . . .  10
       2.5.5.  Flow characteristics provided by application  . . . .  10
       2.5.6.  Action taken by network as result of receiving flow
               characteristics . . . . . . . . . . . . . . . . . . .  10
       2.5.7.  Feedback provided by network  . . . . . . . . . . . .  10
       2.5.8.  Security and Privacy Considerations . . . . . . . . .  10
     2.6.  Mobile Host/App Metadata: Use metadata for
           troubleshooting and network planning  . . . . . . . . . .  10
       2.6.1.  Description of Problem  . . . . . . . . . . . . . . .  10
       2.6.2.  Proposed Solution . . . . . . . . . . . . . . . . . .  10
       2.6.3.  User Benefit  . . . . . . . . . . . . . . . . . . . .  10
       2.6.4.  Operator Benefit  . . . . . . . . . . . . . . . . . .  10
       2.6.5.  Flow characteristics provided by application  . . . .  11
       2.6.6.  Action taken by network as result of receiving flow
               characteristics . . . . . . . . . . . . . . . . . . .  11
       2.6.7.  Feedback provided by network  . . . . . . . . . . . .  11
       2.6.8.  Security and Privacy Considerations . . . . . . . . .  11
     2.7.  Multi-interface selection: Use metadata to help interface
           selection or prioritization . . . . . . . . . . . . . . .  11
       2.7.1.  Description of Problem  . . . . . . . . . . . . . . .  11
       2.7.2.  Proposed Solution . . . . . . . . . . . . . . . . . .  11
       2.7.3.  User Benefit  . . . . . . . . . . . . . . . . . . . .  11
       2.7.4.  Operator Benefit  . . . . . . . . . . . . . . . . . .  11
       2.7.5.  Flow characteristics provided by application  . . . .  11
       2.7.6.  Action taken by network as result of receiving flow
               characteristics . . . . . . . . . . . . . . . . . . .  12
       2.7.7.  Feedback provided by network  . . . . . . . . . . . .  12
       2.7.8.  Security and Privacy Considerations . . . . . . . . .  12
     2.8.  Session Identification: Identification of multiple media
           flows belonging to a common application session . . . . .  12
       2.8.1.  Description of Problem  . . . . . . . . . . . . . . .  12
       2.8.2.  Proposed Solution . . . . . . . . . . . . . . . . . .  12
       2.8.3.  User Benefit  . . . . . . . . . . . . . . . . . . . .  13
       2.8.4.  Operator Benefit  . . . . . . . . . . . . . . . . . .  13
       2.8.5.  Flow characteristics provided by application  . . . .  13
       2.8.6.  Action taken by network as result of receiving flow
               characteristics . . . . . . . . . . . . . . . . . . .  13
       2.8.7.  Feedback provided by network  . . . . . . . . . . . .  13
       2.8.8.  Security and Privacy Considerations . . . . . . . . .  13



Eckel & Reddy            Expires August 18, 2014                [Page 3]

Internet-Draft               AEON Use Cases                February 2014


   3.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   4.  Informative References  . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   Identification and treatment of application flows are critical for
   the successful deployment and operation of applications based on a
   wide range of signaling protocols.  Historically, this functionality
   has been accomplished to the extent possible using heuristics, which
   inspect and infer flow characteristics.  Heuristics may be based on
   port ranges, network separation, or deep packet inspection (DPI),
   e.g. application level gateway (ALG).  Port based solutions suffer
   from port overloading and inconsistent port usage.  Network
   separation solutions are error prone and result in network management
   hassle.  DPI is computationally expensive and becomes a challenge
   with the wider adoption of encrypted signaling and secured traffic.
   An additional drawback of DPI is that the resulting insights are not
   available, or need to be recomputed, at network nodes further down
   the application flow path.

   Application enabled open networking (AEON) allows applications to
   explicitly signal their flow characteristics to the network.  This
   provides network nodes with visibility of the application flow
   characteristics.  These network nodes may take action based on this
   visibility and/or contribute to the flow description.  The resulting
   flow description may be communicated as feedback from the network to
   applications.

   This document describes a set of use cases addressable by AEON.
   Additional details on the AEON are provided in
   [I-D.eckert-intarea-flow-metadata-framework].

2.  Use Cases

   The following use cases have been identified.

   1.  Traffic Prioritization: Consistent experience of video
       conferencing with competing traffic.

   2.  Firewall Traversal: Identification of new applications.

   3.  Load Balancing: Identification of application for better load
       balancing without solely relying on inspection techniques.

   4.  Scavenger class: Creation of a scavenger class.  Use metadata to
       shift high-bandwidth, low priority traffic to off-peak hours.
       TODO: That drifts from a use-case to a solution ("use metadata to



Eckel & Reddy            Expires August 18, 2014                [Page 4]

Internet-Draft               AEON Use Cases                February 2014


       ...").  Also, it appears to mix two things: (a) scavenger class
       and (b) time-shifting traffic.  This is confusing.

   5.  Video Adaptation: Use client metadata to help video bit rate
       selection.

   6.  Mobile Host/App Metadata: Use metadata for troubleshooting and
       network planning.

   7.  Multi-interface selection: Use metadata to help interface
       selection or prioritization.

   8.  Session Identification: Identification of multiple media flows
       belonging to a common application session.

   In describing each use case, the following information is provided.

   o  description of the problem

   o  proposed solution

   o  user benefit

   o  operator benefit

   o  flow characteristics provided by application

   o  action taken by network as result of receiving flow
      characteristics

   o  feedback provided by network

   o  security and privacy considerations

2.1.  Home: Consistent experience of video conferencing with competing
      traffic

2.1.1.  Description of Problem

2.1.2.  Proposed Solution

2.1.3.  User Benefit

2.1.4.  Operator Benefit







Eckel & Reddy            Expires August 18, 2014                [Page 5]

Internet-Draft               AEON Use Cases                February 2014


2.1.5.  Flow characteristics provided by application

2.1.6.  Action taken by network as result of receiving flow
        characteristics

2.1.7.  Feedback provided by network

2.1.8.  Security and Privacy Considerations

2.2.  Firewall Traversal: Identification of new applications

2.2.1.  Description of Problem

   Modern firewalls use application-layer gateways (ALGs) to perform
   policy enforcement.  For example firewalls implement SIP-aware
   Application Layer Gateway function, which examines the SIP signaling
   and opens the appropriate pinholes for the RTP media.  In particular
   firewall extracts media transport addresses, transport protocol and
   ports from session description and creates a dynamic mapping for
   media to flow through.  This model will not work in the following
   cases:

   1.  Session signaling is end-to-end encrypted (say, using TLS).

   2.  Firewall does not understand the session signaling protocol, or
       extensions to the protocol, used by the endpoints (e.g.  WebRTC
       signaling protocols).

   3.  Session signaling and media traverse different firewalls (e.g.,
       signaling exits a network via one firewall whereas media exits a
       network via a different firewall).

   Enterprise networks that use firewalls with restrictive policies
   block new applications like WebRTC and delay deployment of killer
   applications.

2.2.2.  Proposed Solution

   The above problems can be addressed by the host getting authorization
   from the Application Server trusted by the network in order to
   install flows and associated actions (e.g., policies).  PCP third
   party authorization (draft-wing-pcp-third-party-authz-01) solves this
   problem by associating the media session with the signaling session.
   This is done by sending a cryptographic token in the signaling which
   authorizes the firewall mapping for the media session.






Eckel & Reddy            Expires August 18, 2014                [Page 6]

Internet-Draft               AEON Use Cases                February 2014


2.2.3.  User Benefit

   Enterprise networks that use firewalls with restrictive policies can
   deploy new applications at a faster rate for user benefit.

2.2.4.  Operator Benefit

   Enterprise firewalls can enforce restrictive policies without the
   need to be enhanced to perform ALG on new applications.  For example
   Enterprise firewall could have granular policies to permit peer-to-
   peer UDP media session only when the call is initiated using the
   selected WebRTC server (Dr. Good) it trusts and block others (Dr.
   Evil).  PCP-aware firewalls can enforce such granular security
   policies without performing ALG on the session signaling protocols.
   This mechanism can be used by any other Application Function trusted
   by the network to permit time-bound, encrypted, peer-to-peer traffic.

2.2.5.  Flow characteristics provided by application

   The client requests dynamic mappings to permit flows required by the
   application.  This request includes a cryptographic token and
   characteristics of the flow, such as the anticipated bandwidth needs
   as well as the tolerance to delay, loss, and jitter.

2.2.6.  Action taken by firewall as result of receiving flow
        characteristics

   The firewall uses the client request to permit and prioritize the
   traffic associated with those flows.  The cryptographic token
   provides authorization for the flows and their prioritization.

2.2.7.  Feedback provided by firewall

   Firewall matches the authorization data with what is requested in the
   request sent by the client.  If the authorization sets match, the
   firewall processes the request made by the client.  If the token is
   invalid or the request exceeds what is authorized by the token then
   firewall rejects the request.

2.2.8.  Security and Privacy Considerations

2.3.  Load Balancing: Identification of application for better load
      balancing without solely relying on inspection techniques








Eckel & Reddy            Expires August 18, 2014                [Page 7]

Internet-Draft               AEON Use Cases                February 2014


2.3.1.  Description of Problem

2.3.2.  Proposed Solution

2.3.3.  User Benefit

2.3.4.  Operator Benefit

2.3.5.  Flow characteristics provided by application

2.3.6.  Action taken by network as result of receiving flow
        characteristics

2.3.7.  Feedback provided by network

2.3.8.  Security and Privacy Considerations

2.4.  Scavenger class: Creation of a scavenger class.  Use metadata to
      shift high-bandwidth, low priority traffic to off-peak hours

2.4.1.  Description of Problem

2.4.2.  Proposed Solution

2.4.3.  User Benefit

2.4.4.  Operator Benefit

2.4.5.  Flow characteristics provided by application

2.4.6.  Action taken by network as result of receiving flow
        characteristics

2.4.7.  Feedback provided by network

2.4.8.  Security and Privacy Considerations

2.5.  Video Adaptation: Use client metadata to help video bit rate
      selection

   HTTP Adaptive Streaming (HAS) is an umbrella term for various HTTP-
   based streaming technologies that allow a client to adaptively switch
   between multiple bitrates, depending on current network conditions.
   HAS client first requests and receives a Manifest File, and then,
   after parsing the information in the Manifest File, proceeds with
   sequentially requesting the chunks listed in the Manifest File.





Eckel & Reddy            Expires August 18, 2014                [Page 8]

Internet-Draft               AEON Use Cases                February 2014


2.5.1.  Description of Problem

   The problems with HAS are:

   o  HAS client selects the initial bitrate without knowing the current
      network conditions which could cause start-up delay and frame
      freezes while a lower bitrate chunk is being retrieved.  HAS
      client does not have a mechanism to signal the flow
      characteristics and flow priority to the network.

   o  HAS server can mark the packets appropriately but setting DSCP has
      limitations.  DSCP value may not be preserved or honored over the
      Internet and OS may not allow to set DSCP values.

   o  Content Providers may have agreements with ISPs and need a
      mechanism to convey the flow characteristics and flow priority to
      the ISP.  Existing mechanisms and the associated limitations are:

      1.  ISP can be configured with the IP addresses of content
          providers to prioritize the traffic originating from those
          servers.  The limitations with this approach are ISP has to
          keep track of content providers IP addresses.  With CDNI
          (Content Delivery Network InterConnection) content could be
          served either from uCDN (upstream CDN) or any of a number of
          dCDNs (downstream CDN) and it will not be possible to manually
          track the IP addresses of all the CDN surrogates.  There is
          also no way to differentiate content which could be available
          in different bitrates.

      2.  If HAS client is behind NAT and content provider uses RESTful
          API (OneAPI) to install differentiated QoS then ISP will
          struggle to find the pre-NAT information.  Content provider
          also needs to be aware of the ISP to which the client is
          attached and the IP address of the Policy Decision Point (PDP)
          in the ISP to which it needs to signal the flow
          characteristics.

   o  ISP can use DPI to prioritize one-way video streaming content but
      is expensive and fails if the traffic is encrypted.

2.5.2.  Proposed Solution

   If ISP has agreement with content provider then HAS client can use
   third party authorization to request network resources.  At a high
   level, this authorization works by the client first obtaining a
   cryptographic token from the authorizing network element, then
   including that token in the request along with relevant flow
   characteristics.  ISP validates the token and grants the request.



Eckel & Reddy            Expires August 18, 2014                [Page 9]

Internet-Draft               AEON Use Cases                February 2014


2.5.3.  User Benefit

   AEON helps increase the average play quality, reduces the start-up
   delay and frame freezes by avoiding attempt to retrieve a too high-
   bit rate chunk etc thus improving the quality of experience for end
   user.

2.5.4.  Operator Benefit

   Network Operators can recognize and prioritize one-way video
   streaming content.

2.5.5.  Flow characteristics provided by application

   HAS client signals the flow characteristics such as the anticipated
   bandwidth needs as well as the tolerance to delay, loss, and jitter.

2.5.6.  Action taken by network as result of receiving flow
        characteristics

   Subject to local policies, a network node might perform bandwidth
   counting, or reconfigure the underlying network so that additional
   bandwidth is made available for this particular flow, or might
   perform other actions.

2.5.7.  Feedback provided by network

   The network responds that the client request can be fully or
   partially accommodated.  It also notifies the client when conditions
   change.

2.5.8.  Security and Privacy Considerations

2.6.  Mobile Host/App Metadata: Use metadata for troubleshooting and
      network planning

2.6.1.  Description of Problem

2.6.2.  Proposed Solution

2.6.3.  User Benefit

2.6.4.  Operator Benefit








Eckel & Reddy            Expires August 18, 2014               [Page 10]

Internet-Draft               AEON Use Cases                February 2014


2.6.5.  Flow characteristics provided by application

2.6.6.  Action taken by network as result of receiving flow
        characteristics

2.6.7.  Feedback provided by network

2.6.8.  Security and Privacy Considerations

2.7.  Multi-interface selection: Use metadata to help interface
      selection or prioritization

2.7.1.  Description of Problem

   An increasing number of hosts are operating in multiple-interface
   environments and a host with multiple interfaces needs to choose the
   best interface for communication.  Oftentimes, this decision is based
   on a static configuration and does not consider the link
   characteristics of that interface, which may affect the user
   experience.  The network interfaces may have different link
   characteristics, but that will not be known without the awareness of
   the upstream and downstream characteristics of the access link.

2.7.2.  Proposed Solution

   TODO

2.7.3.  User Benefit

   Applications can choose the best interface for communication using
   AEON.

2.7.4.  Operator Benefit

   The network that can provide the requested flow characteristics will
   be selected by the application thus increasing the subscriber base of
   the operator.

2.7.5.  Flow characteristics provided by application

   Application signals flow characteristics over multiple interfaces and
   based on the response from its various interfaces sorts the source
   addresses according to the link capacity characteristics.  Source
   addresses from the interface which best fulfills the desired flow
   characteristics are assigned the highest priority and would be tried
   first to communicate with the server or remote peer.  For example
   draft-reddy-mmusic-ice-best-interface-pcp-00 explains the mechanism
   where Interactive Connectivity Establishment (ICE) agent on a host



Eckel & Reddy            Expires August 18, 2014               [Page 11]

Internet-Draft               AEON Use Cases                February 2014


   with multiple interfaces uses AEON to determine the link
   characteristics of the host's interfaces, which influences the ICE
   candidate priority.  Similarly draft-wing-mptcp-pcp-00 explains how
   Multipath TCP (MPTCP) can select the best path when multiple paths
   are available.

2.7.6.  Action taken by network as result of receiving flow
        characteristics

2.7.7.  Feedback provided by network

2.7.8.  Security and Privacy Considerations

2.8.  Session Identification: Identification of multiple media flows
      belonging to a common application session

2.8.1.  Description of Problem

   Many end-to-end application sessions involve multiple application
   protocols, devices and administrative domains.  These sessions
   involve multiple media flows (e.g. an audio flow and a video flow for
   a video call, media flows between different entities in a
   supplementary service session consisting of multiple SIP dialogs or
   H.323 calls).  Media flows may be added/removed from a application
   session during the lifetime of the session.  From within the network,
   determining which media flows are associated with each application
   session is often difficult, making it hard to provide application
   level troubleshooting, traffic analysis, and QoS.

2.8.2.  Proposed Solution

   Including a session identify (e.g. as defined in
   [I-D.ietf-insipid-session-id-reqts]) in the flow characteristics
   communicated by the application to the network would allow the
   network to identify media flows belonging to a common application
   session.  This visibility would enable the following:

   o  network troubleshooting and traffic analysis tools to correctly
      associate media flows with application sessions

   o  media flows that are part of established application sessions to
      be identified (e.g. the triggered call in the case of a transfer)
      and given dedicated QoS.  Preserving established sessions
      generally is higher priority than setting up new sessions (except
      when there is some form of multi-level preemption).  Giving more
      bandwidth to additional flows on established sessions might cause
      some newer sessions to fail due to resource unavailability while




Eckel & Reddy            Expires August 18, 2014               [Page 12]

Internet-Draft               AEON Use Cases                February 2014


      established sessions continue without degradation, which is the
      preferred outcome in most cases.

2.8.3.  User Benefit

   Users receive more predictable and reliable QoS for their application
   sessions.

2.8.4.  Operator Benefit

   Operators are able to perform traffic analysis and troubleshooting at
   the application level, and they are able to provide QoS at the
   application level rather than only at the media flow level.

2.8.5.  Flow characteristics provided by application

   The application provides a common session id as metadata for all its
   media flows throughout the lifetime of the session.

2.8.6.  Action taken by network as result of receiving flow
        characteristics

   The network identifies all media flows associated with a given
   session.  This information may be used to provide application level
   QoS, preserving established sessions and/or giving more bandwidth to
   additional flows on established sessions.

2.8.7.  Feedback provided by network

   The network may provide feedback to the application indicating the
   amount of bandwidth it expects to be able to provide for its session.
   It may also be provide indications of the expected amount of delay,
   jitter, and loss the application should be prepared to tolerate.

2.8.8.  Security and Privacy Considerations

3.  Acknowledgements

   The authors thank the attendees of the Bar BoF for contributing
   towards this set of use cases.

4.  Informative References

   [I-D.eckert-intarea-flow-metadata-framework]
              Eckert, T., Penno, R., Choukir, A., and C. Eckel, "A
              Framework for Signaling Flow Characteristics between
              Applications and the Network", draft-eckert-intarea-flow-
              metadata-framework-02 (work in progress), October 2013.



Eckel & Reddy            Expires August 18, 2014               [Page 13]

Internet-Draft               AEON Use Cases                February 2014


   [I-D.ietf-insipid-session-id-reqts]
              Jones, P., Salgueiro, G., Polk, J., Liess, L., and H.
              Kaplan, "Requirements for an End-to-End Session
              Identification in IP-Based Multimedia Communication
              Networks", draft-ietf-insipid-session-id-reqts-11 (work in
              progress), February 2014.

Authors' Addresses

   Charles Eckel
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   US

   Email: eckelcu@cisco.com


   Tirumaleswar Reddy
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marathalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: tireddy@cisco.com

























Eckel & Reddy            Expires August 18, 2014               [Page 14]