[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-ietf-bier-problem-statement

Internet Engineering Task Force                              G. Shepherd
Internet-Draft                                                     Cisco
Intended status: Informational                               A. Dolganow
Expires: August 10, 2015                                  Alcatel-Lucent
                                                                A. Gulko
                                                         Thomson Reuters
                                                        February 6, 2015


       Bit Indexed Explicit Replication (BIER) Problem Statement
                draft-shepherd-bier-problem-statement-02

Abstract

   There is a need to simplify network operations for multicast
   services.  Current solutions require a tree-building control plane to
   build and maintain end-to-end tree state per flow, impacting router
   state capacity and network convergence times.  Multi-point tree
   building protocols are often considered complex to deploy and debug
   and may include mechanics from legacy use-cases and/or assumptions
   which no longer apply to the current use-cases.  When multicast
   services are transiting a provider network through an overlay, the
   core network has a choice to either aggregate customer state into a
   minimum set of core states resulting in flooding traffic to unwanted
   network end-points, or to map per-customer, per-flow tree state
   directly into the provider core state amplifying the network-wide
   state problem.

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 10, 2015.







Shepherd, et al.         Expires August 10, 2015                [Page 1]


Internet-Draft           BIER Problem Statement            February 2015


Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Objectives  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Deering's Multicast Model . . . . . . . . . . . . . . . . . .   5
   4.  Network Based Source Discovery  . . . . . . . . . . . . . . .   7
   5.  Receiver Driven State . . . . . . . . . . . . . . . . . . . .   8
   6.  Multicast Virtual Private Networks  . . . . . . . . . . . . .   9
   7.  Overlay . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   8.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     11.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Appendix A.  Additional Stuff . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   There is a need to simplify network operations for multicast
   services.  Current solutions require a tree-building control plane,
   to build and maintain end-to-end tree state per flow, impacting
   router state capacity and network convergence times.  Multi-point
   tree building protocols are often considered complex to deploy and
   debug and include mechanics from legacy use-cases and/or assumptions
   which may no longer apply to the current use-case.  When multicast
   services are transiting a provider network through an overlay, the
   core network has a choice to either aggregate customer state into a
   minimum set of core states resulting in flooding traffic to unwanted
   network end-points, or to map per-customer, per-flow tree state




Shepherd, et al.         Expires August 10, 2015                [Page 2]


Internet-Draft           BIER Problem Statement            February 2015


   directly into the provider core state amplifying the network-wide
   state problem.

   This document attempts to discuss the uses, benefits and challenges
   of the current multicast solutions and to put them in an historical
   context to better understand why we are where we are today, and to
   provide a framework for discussion around new solutions that may
   address our current requirements and challenges.

1.1.  Requirements Language

   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 RFC 2119 [RFC2119].

2.  Objectives

   IP Multicast services have been widely adopted in networks where the
   benefits of efficient, concurrent delivery of content to a
   sufficiently large set of receivers outweighs the complexity and
   challenges of deploying and managing the current set of multicast
   protocols.  These deployments are primarily dedicated multicast
   islands with very little cross-domain inter-networking, and fall
   short of the early dreams of a multicast enabled Internet.

   Multicast began with a large set of requirements shoehorned into a
   single, complex protocol.  Over time, multicast protocols essentially
   devolved into a set of more simple components to overcome the
   original complexity, and to address a growing set of use cases.  Many
   of the early complexity can be avoided today by correctly selecting
   your service model and protocols.  But the standard set of protocols
   available can still be considered overloaded for various reasons.

   The current problems associated with the today's multicast solutions
   can be stated as follows:

      - Current multicast methods all require explicit tree building
      protocols, thereby incurring a lot of state in the transit nodes.

      - Receiver driven tree state uses Reverse Path Forwarding (RPF) to
      build the trees toward the root which often results in multicast
      forwarding following different paths than unicast forwarding
      between the same two endpoints.

      - Multicast convergence times are negatively impacted by tree
      state.  Any network transition requires unicast to first converge.
      Once unicast has converged multicast must then recalculate RPF for
      every tree and rebuild the trees by sending join messages toward



Shepherd, et al.         Expires August 10, 2015                [Page 3]


Internet-Draft           BIER Problem Statement            February 2015


      the new RPF neighbor per tree.  Joins toward a common RPF neighbor
      can be aggregated but only up to the link MTU.  In large multicast
      deployments this can result in multicast convergence times of up
      to a minute or more.  In extreme cases the active state may time
      out before all the new joins are sent and received resulting in
      multicast to permanently fail after a network failure event even
      though there is a restored path.  This has put an upward bound on
      the amount of state a multicast network can support.

      - Current multicast methods, if they are to provide optimal
      delivery of multicast packets, require one explicitly built tree
      per multicast flow; there is no way to aggregate flows (having one
      state for multiple flows) without sacrificing optimal delivery.
      In the case of Multicast Virtual Private Network (MVPN)
      deployments, the operator is forced to choose between unwanted
      flooded traffic across an aggregate state entry and exposing
      customer state in the core.

      - Some multicast solutions include data-driven events.  This has
      required specialized capabilities to be integrated into routing
      equipment to protect the control plane from the multicast data
      plane increasing the cost of multicast support in routing
      equipment.

      - Maintaining and troubleshooting multicast networks can be very
      difficult.  The available solutions are so different than unicast,
      often revealing unique corner cases that specialized training and
      skills, and frequently dedicated staff are required just to
      operate multicast services on a network.

      - Current Multicast Virtual Private Networks [RFC6513](MVPN)
      introduced Border Gateway Protocol[RFC4271](BGP) routes for
      neighbour discovery and Protocol Independent Multicast[RFC4601]
      (PIM) Join/Prune propagation.  In some deployments when many
      Multicast MVPNs with many Provider Edge (PE) routers exist in a
      network and at least some of those MVPNs have a large number of
      customer-multicast flows, the resulting tax on BGP may be deemed
      undesired as millions of BGP routes can easily result from
      multicast deployments.  Therefore a solution that allows large
      MVPN scale with large number of edge PEs and c-multicast flows per
      MVPN is desired.

      - With the introductions of Segment Routing, some networks may
      elect to remove the Multiprotocol Lable Switching[RFC3031](MPLS)
      control plane and rely on Interior Gateway Protocol-only or
      Software Defined Networking-based Segment Routing.  In such
      networks the alternative to existing mechanisms is needed for
      multicast.  Removing the MPLS control plane for unicast makes



Shepherd, et al.         Expires August 10, 2015                [Page 4]


Internet-Draft           BIER Problem Statement            February 2015


      little sense unless the multicast control plane also gets
      simplified.

      - The benefits of multi-point services are well understood, but
      the challenges with the current solutions often result in a failed
      cost/benefit analysis.  Today only those networks with an
      overwhelming business need have successful multicast deployments,
      and the rest of the community have come to think of multicast as a
      failed technology.

   How did we get here?  What follows is a semi-chronological tour
   through the devolution of multicast protocols, solutions, and use-
   cases, describing why earlier complexities and challenges existed,
   and how they were overcome.  This may help frame future work to
   overcome our current challenges.

3.  Deering's Multicast Model

   The original Multicast Extensions to the Internet Protocol [RFC0966]
   and Host Extensions for IP Multicasting [RFC1112]were envisioned by
   Stephen Deering as part of his graduate work at Stanford University.
   The need for a multi-point service model was motivated by the advent
   and deployment of layer3 network topologies breaking existing layer2
   applications.  The need arose to create an underlay service with the
   characteristics of a broadcast domain to allow these layer2
   applications to continue to function without modification across a
   layer3 infrastructure.

   Though the community quickly saw the value and envisioned many other
   uses for a multi-point service model, a broadcast domain remained the
   target model for the solution and the list of requirements focused
   around those of a broadcast domain.  For simplicity the rules of this
   underlay broadcast domain can be summed up as follows: anyone can
   send packets into the domain; all members will receive all packets
   sent into the domain.  In order for these layer2 applications to
   function across this broadcast domain overlay, all of the functions
   to provide this service were loaded onto network layer.

   This new multi-point model was called Multicast.  The first multicast
   solution adopted by the IETF was Distance Vector Multicast Routing
   Protocol [RFC1075](DVMRP).  As the name implies, DVMRP uses a
   distance-vector routing algorithm derived from Routing Information
   Protocol [RFC1058](RIP) in combination with the Truncated Reverse
   Path Broadcasting (TRPB) algorithm to build and maintain tree state
   and forward multicast packets along these distribution trees.  The
   Internet Assigned Numbers Authority (IANA) was asked to reserve a
   portion of the global IPv4 address space for multicast destination




Shepherd, et al.         Expires August 10, 2015                [Page 5]


Internet-Draft           BIER Problem Statement            February 2015


   addresses required by this model, and in response 224/4 was allocated
   as the Class D address space for IP Multicast group addresses.

   DVMRP has no concept of a "join" message.  All new source packets for
   any given group were simply flooded downstream--essentially
   broadcasted--following the DVMRP topology.  Each leaf of the tree was
   responsible for sending Non Membership Reports (NMR--prunes) toward
   the source if there were no downstream receivers for the group.  This
   mechanism came to be known as flood-and-prune, and is a very
   primitive form of network-based source discovery that all the
   contemporary applications came to depend on.  These contemporary
   applications were inherently many-to-many either by the nature of the
   data distribution model, or at the least depended on the many-to-many
   nature of the network-based-source discovery mechanism.

   DVMRP also incorporated the IETF's first specification of an
   encapsulated overlay.  It was clear that this new model would not be
   supported by every node in the path, and an encapsulation allowed
   early adopters to build a global multi-point, or multicast capable
   topology as an overlay.

   For clarity of discussion, the functions of the Deering model can be
   described as:

      - Tree building and maintenance

      - Network-based source discovery

      - Source route information

      - Overlay mechanism - tunneling

   DVMRP was considered over-loaded in that it carries network source
   routing information within the protocol in parallel to any existing
   Interior Gateway Protocol (IGP) generated local routing table.  The
   next generation goal was to focus on the multi-point services needed
   for the model but to use the local, native routing table as needed
   for Reverse Path Check (RPF).  From this came the advent of Protocol
   Independent Multicast Sparse Mode [RFC4601](PIM-SM) and Protocol
   Independent Multicast Dense Mode [RFC3973](PIM-DM).  PIM removed any
   embedded source routing function from the protocol, and instead
   relied on the exiting routing table as generated from the deployed
   IGP.  PIM also removed any overlay functionality, but retained
   network-based source discovery as a fundamental part of the protocol.
   Oops.






Shepherd, et al.         Expires August 10, 2015                [Page 6]


Internet-Draft           BIER Problem Statement            February 2015


4.  Network Based Source Discovery

   The Deering model introduced the concept of a Group address (G)
   representing a single broadcast domain.  Any source is allowed to
   send to the group address and the multicast routing infrastructure
   will build tree state from every source to all interested receivers.
   All group members only need to signal their G membership to the
   network and the network will ensure that all source traffic sending
   to that same group address will arrive at all group members.  The
   network-based source discovery operation providing these functions
   was intended to provide operational constancy with a layer2 broadcast
   domain, but comes at significant cost.

   Allowing any source to send to a group is an obvious security
   vulnerability.  Many implementations today provide various layers of
   access control both at the edges and core of the network just to
   overcome the security concerns for the basic operation of the
   multicast network.

   Network-based source discovery methods can be grouped into two types;
   flood and prune (DVMRP, PIM-DM), or explicit join (PIM-SM).  Both
   methods depend on the arrival of data to trigger complex network
   functions to build and maintain the per-source distribution of data
   for every group.  Multicast is often considered complex, fragile, and
   difficult to troubleshoot, but it is most often the network-based
   source discovery functions that are the cause of this reputation.

   The majority of the use-cases for multicast today are for content
   with well-know sources.  The development of Internet Group Membership
   Protocol [RFC3376] (IGMPv3) provided a mechanism for group members to
   signal interest in a source and a group, eliminating the need for
   network-based source discovery, and facilitating the advent of Source
   Specific Multicast [RFC4607] (SSM).  Many operators still ask how
   potential SSM group members learn about the sources.  The answer is
   simply to use the same mechanism in which they learned about the
   group - out-of-band.  Source (and group) discovery mechanisms are
   better served at the application layer for most use-cases.  With SSM
   multicast content can be forwarded and constrained to a single
   source-rooted tree, or (S,G) channel which has several key benefits:

      - Simplified configuration and operation

      - Elimination of rouge sources 'stealing' receivers

      - Elimination of rouge sources consuming network resources

      - Elimination of group address resource restrictions




Shepherd, et al.         Expires August 10, 2015                [Page 7]


Internet-Draft           BIER Problem Statement            February 2015


5.  Receiver Driven State

   Today's multicast solutions are primarily receiver driven.  This is a
   logical approach in that it is the receiver that decides if and when
   to join or leave a group or channel.  Receiver driven distribution
   trees built hop-by-hop are an efficient way to dynamically build and
   scale very large membership fanout.  It can be argued that a receiver
   driven tree's radius can scale infinitely without impact to any
   upstream segment or node for that tree.  But it does then require
   forwarding state for each tree, or pre-flow state.

   The joins propagate upstream from the receiver toward the source or
   root of the tree, following the unicast routing table.  But this
   reverse path may differ from the optimal unicast forwarding path from
   the source to the receiver.  The result is multicast traffic
   potentially taking a different forwarding path than unicast traffic
   between the same to network endpoints.  This can often complicate
   network and traffic engineering.

   Each of the existing multicast solutions today, native or overlay,
   builds and maintains forwarding state per flow, or aggregates some
   flows into a subset of flow-states.  On the surface this may look
   like an unbounded problem, but in actuality the flow state is only
   present along the branches of the tree, and no one router needs to
   maintain global tree state.  Router state capacity is not infinite,
   and this coupling of receiver actions to network state is a potential
   Denial of Service (DoS) vector.  Most implementations today have
   provided filtering and state-limiting capabilities to secure the
   multicast infrastructure from this vulnerability.

   Increasing multicast forwarding state can also negatively impact
   network convergence performance.  Unicast is only concerned with
   topology, and any topology changes can converge in a relatively
   bounded amount of time.  The same topology change requires the
   multicast protocol to rebuild the forwarding state for every active
   flow.  The resulting multicast convergence times are directly
   dependent on the amount of flow state affected by the convergence
   event.  In extreme cases, the sending, receiving, and processing of
   the join state for all active flows can exceed the flow state timers
   resulting in a race condition in which convergence never occurs.
   Today's implementations have had to incorporate various proprietary
   solutions to improve network convergence times in large flow-state
   multicast deployments.

   The pros and cons of receiver driven state are as follows:

      Pros:




Shepherd, et al.         Expires August 10, 2015                [Page 8]


Internet-Draft           BIER Problem Statement            February 2015


         Infinitely scales distribution radius

         Aligns with receiver driven join model

      Cons:

         Potential state DoS vector

         Host driven network events

         Unbounded per-flow state

         Unicast/Multicast traffic divergence

         Non-deterministic join latency

         Convergence times increasing with flow-state

6.  Multicast Virtual Private Networks

   Multicast Virtual Private Networks [RFC6513](MVPN) are solutions
   which allow a core network to transit edge network multicast flows
   over a core transit network to and from only those MVPN member nodes,
   without exposing the edge network addressing into the core network
   forwarding state.  The solutions attempt to minimize core state by
   aggregating trees per-VRF/PE.  But this aggregation has the side
   affect of sending all multicast traffic from that VRF/PE to all other
   VRF/PE members, whether or not they have down stream flow state.

   Various optimizations are available to selectively de-aggregate flow
   state to better constrain the traffic distribution to only those VRF/
   PEs with active state.  This becomes a trade off between unwanted
   traffic and an increase in core flow state.  These solutions are
   often data driven resulting in core router state being triggered by
   date and receiver events.

   In addition to a potential BGP route explosion due to an MVPN
   deployment scale as discussed in section 2, another issue with MVPN
   relates to architectures used when MVPN deployments require both
   video-distribution-like model, well served by point-to-multipoint
   (P2MP) connectivity, and many-to-many model requiring Multipoint-to-
   multipoint (MP2MP) connectivity.  Today, if both models are deployed
   in a single network, either MP2MP or a mesh of P2MP trees needs to be
   established, or dual P2MP/MP2MP mLDP architecture may be used, or
   MP2MP mLDP can be used for both P2MP and MP2MP connectivity.  None of
   those models is optimal as each requires a trade-off between
   supported protocols, optimal delivery, and operational complexity.




Shepherd, et al.         Expires August 10, 2015                [Page 9]


Internet-Draft           BIER Problem Statement            February 2015


7.  Overlay

   Deering had the correct insight to assume not every node in a network
   would be capable of natively transiting multicast flows.  The
   migration to PIM was an attempt to move to a completely native model,
   which was the right direction.  But in this move it also abandoned
   any other solution for incorporating an underlay into the topology
   for those portions of the network which for whatever reason do not
   support native multicast.  Early deployments of PIM often
   incorporated static Generic Routing Encapsulation [RFC2784](GRE)
   tunnels between PIM domains in an attempt to create an inter domain
   multicast deployment.

   Static tunneling has it's use cases and benefits, but it is not the
   ideal tool to dynamically stitch together a large and topologically
   diverse receiver population.  A receiver driven distribution model
   would be better served with a receiver driving overlay mechanism.
   This would indicate that when overlay was removed from the tree
   building protocol it should have migrated to IGMPv3 and Multicast
   Listener Discovery [RFC3810](MLDv2), the membership protocol, but it
   was seen as a necessary requirement at that time.  To fill this
   requirement today Automatic Multicast Tunnels (AMT) is being
   progressed as the overlay standard for bridging multicast interested
   receivers over unicast only intermediate networks.

8.  Summary

   Multicast began with a heavily overloaded protocol DVMRP, and has
   evolved over time by removing functionality from this all-in-one
   solution, and off-loading certain function to either more specialized
   protocols or existing protocols and functions.  Multicast has what
   may be the unique distinction of starting very complex, but evolving
   through more simple stages along the way.  It may be time to consider
   the next step in the evolution toward simplicity.

   Today we depend on receiver driven joins propagating end-to-end from
   receivers toward sources, and maintaining per-flow state in every
   node along the path.  This state crosses administrative domains.
   Unicast has a simple model where local specificity stays local and
   does not directly impact the global table.  Multicast state has no
   administrative boundaries today.  It may be beneficial to consider
   the autonomy of networks in the path, and their specific topology and
   requirements.  PIM successfully utilizes the available routing table
   for RPF checks and joins.  This route table may also be considered as
   a source of topology information for a set of receiver nodes within a
   given network.





Shepherd, et al.         Expires August 10, 2015               [Page 10]


Internet-Draft           BIER Problem Statement            February 2015


9.  IANA Considerations

   This memo includes no request to IANA.

   All drafts are required to have an IANA considerations section (see
   Guidelines for Writing an IANA Considerations Section in RFCs
   [RFC5226] for a guide).  If the draft does not require IANA to do
   anything, the section contains an explicit statement that this is the
   case (as above).  If there are no requirements for IANA, the section
   will be removed during conversion into an RFC by the RFC Editor.

10.  Security Considerations

   All drafts are required to have a security considerations section.
   See RFC 3552 [RFC3552] for a guide.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

11.2.  Informative References

   [RFC0966]  Deering, S. and D. Cheriton, "Host groups: A multicast
              extension to the Internet Protocol", RFC 966, December
              1985.

   [RFC1058]  Hedrick, C., "Routing Information Protocol", RFC 1058,
              June 1988.

   [RFC1075]  Waitzman, D., Partridge, C., and S. Deering, "Distance
              Vector Multicast Routing Protocol", RFC 1075, November
              1988.

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, August 1989.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.



Shepherd, et al.         Expires August 10, 2015               [Page 11]


Internet-Draft           BIER Problem Statement            February 2015


   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552, July
              2003.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [RFC3973]  Adams, A., Nicholas, J., and W. Siadak, "Protocol
              Independent Multicast - Dense Mode (PIM-DM): Protocol
              Specification (Revised)", RFC 3973, January 2005.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC6513]  Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
              VPNs", RFC 6513, February 2012.

Appendix A.  Additional Stuff

   This becomes an Appendix.

Authors' Addresses

   Greg Shepherd (editor)
   Cisco
   170 W. Tasman Dr.
   San Jose
   US

   Email: gjshep@gmail.com






Shepherd, et al.         Expires August 10, 2015               [Page 12]


Internet-Draft           BIER Problem Statement            February 2015


   Andrew Dolganow (editor)
   Alcatel-Lucent
   600 March Rd.
   Ottawa, Ontario  K2K 2E6
   Canada

   Email: andrew.dolganow@alcatel-lucent.com


   Arkadiy Gulko (editor)
   Thomson Reuters

   Email: arkadiy.gulko@thomsonreuters.com






































Shepherd, et al.         Expires August 10, 2015               [Page 13]

Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/