Network Working Group                               I. Wijnands (Editor)
Internet-Draft                                                 T. Eckert
Intended status: Standards Track                     Cisco Systems, Inc.
Expires: July 22, August 30, 2010                                      N. Leymann
                                                        Deutsche Telekom
                                                            M. Napierala
                                                               AT&T Labs
                                                        January 18,
                                                       February 26, 2010

mLDP based in-band signaling for Point-to-Multipoint and Multipoint-to-
                    Multipoint Label Switched Paths
               draft-ietf-mpls-mldp-in-band-signaling-00
               draft-ietf-mpls-mldp-in-band-signaling-01

Abstract

   Suppose an IP multicast tree, constructed by Protocol Independent
   Multicast (PIM), needs to pass through an MPLS domain in which
   Multipoint LDP (mLDP) Point-to-Multipoint and/or Multipoint-to-
   Multipoint Labels Switched Paths (LSPs) can be created.  The part of
   the IP multicast tree that traverses the MPLS domain can be
   instantiated as a multipoint LSP.  When a PIM Join message is
   received at the border of the MPLS domain, information from that
   message is encoded into mLDP messages.  When the mLDP messages are
   received at the border of the next IP domain, the encoded information
   is used to generate PIM messages that can be sent through the IP
   domain.  The result is an IP multicast tree consisting of a set of IP
   multicast sub-trees that are spliced together with a multipoint LSP.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 22, August 30, 2010.

Copyright Notice

   Copyright (c) 2010 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 (http://trustee.ietf.org/license-info). document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Abstract

   When an IP multicast tree needs to pass through an MPLS domain, it is
   advantageous to map  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the tree to a Point-to-Multipoint or Multipoint-
   to-Multipoint Label Switched Path. Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

   This document specifies a way to
   provide a one-one mapping between IP multicast trees and Label
   Switched Paths using mLDP signaling. may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The IP multicast control
   messages are translated into MPLS control messages when they enter person(s) controlling the MPLS domain, and are translated back into IP multicast control
   messages at copyright in some of this
   material may not have granted the IETF Trust the far end right to allow
   modifications of such material outside the MPLS domain.  The IP multicast control
   information is coded into IETF Standards Process.
   Without obtaining an adequate license from the MPLS control information person(s) controlling
   the copyright in such a way
   as materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to ensure that a single Multipoint Label Switched Path gets set up format
   it for each IP multicast tree. publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4  3
     1.1.  Conventions used in this document  . . . . . . . . . . . .  4  3
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4  3
   2.  In-band signaling for MP LSPs  . . . . . . . . . . . . . . . .  5  4
     2.1.  Transiting Unidirectional IP multicast source trees . . . . . . . . Shared Trees  . . .  6  5
     2.2.  Transiting IP multicast bidirectional source trees . . . . . . .  6
     2.3.  Transiting IP multicast shared Trees . . . .  5
     2.3.  Transiting IP multicast bidirectional trees  . . . . . . .  7  6
   3.  LSP opaque encodings . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Transit IPv4 Source TLV  . . . . . . . . . . . . . . . . .  7
     3.2.  Transit IPv6 Source TLV  . . . . . . . . . . . . . . . . .  8  7
     3.3.  Transit IPv4 bidir TLV . . . . . . . . . . . . . . . . . .  8
     3.4.  Transit IPv6 bidir TLV . . . . . . . . . . . . . . . . . .  9  8
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10  9
   5.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 10  9
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Contributing authors . . . . . . . . . . . . . . . . . . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

1.  Introduction

   The mLDP specification [I-D.ietf-mpls-ldp-p2mp] describes mechanisms
   for creating point-to-multipoint (P2MP) and multipoint-to-multipoint
   MP2MP LSPs.  These LSPs are typically used for transporting enduser
   multicast packets.  However, the mLDP specification
   [I-D.ietf-mpls-ldp-p2mp] does not provide any rules for associating
   particular enduser multicast packets with any particular LSP.  Other
   drafts, like [I-D.ietf-l3vpn-2547bis-mcast], describe applications in
   which out-of-band signaling protocols, such as PIM and BGP, are used
   to establish the mapping between an LSP and the multicast packets
   that need to be forwarded over the LSP.

   This draft describes an application in which the information needed
   to establish the mapping between an LSP and the set of multicast
   packets to be forwarded over it is carried in the "opaque value"
   field of an mLDP FEC element.  When an IP multicast tree (either a
   source-specific tree or a bidirectional tree) enters the MPLS
   network, the IP multicast control messages used to set up network
   the tree
   are translated into mLDP messages.  The (S,G) or (*,G) information from the IP multicast control messages plane
   state is carried in the opaque value field of the mLDP FEC message.
   As the tree leaves the MPLS network, this information is extracted
   from the FEC element and used to build the IP multicast control
   plane.  PIM messages that are can be sent outside the MPLS domain.  Note that
   although the IP multicast PIM control messages are sent periodically, the mLDP
   messages are not.

   Each IP multicast tree is mapped one-to-one to a P2MP or MP2MP LSP in
   the MPLS network.  This type of service works well if the number of
   LSPs that are created is under control of the MPLS network operator,
   or if the number of LSPs for a particular service are known to be
   limited in number.

1.1.  Conventions used in this document

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

1.2.  Terminology

   IP multicast tree :  An IP multicast distribution tree identified by
      an source IP address and/or IP multicast destination address, also
      refered to as (S,G) and (*,G).

   mLDP :  Multicast LDP.

   Transit LSP :  An P2MP or MP2MP LSP whose FEC element contains the
      (S,G) or (*,G) identifying a particular IP multicast distribution
      tree.

   In-band signaling :  Using the opaque value of a mLDP FEC element to
      signal
      carry the (S,G) or (*,G) indentifying a particular IP multicast route information.
      tree.

   P2MP LSP:  An LSP that has one Ingress LSR and one or more Egress
      LSRs.

   MP2MP LSP:  An LSP that connects a set of leaf nodes, acting
      indifferently as ingress or egress.

   MP LSP:  A multipoint LSP, either a P2MP or an MP2MP LSP.

   Ingress LSR:  Source of the P2MP LSP, also referred to as root node.

   Egress LSR:  One of potentially many destinations of an LSP, also
      referred to as leaf node in the case of P2MP and MP2MP LSPs.

   Transit LSR:  An LSR that has one or more directly connected
      downstream LSRs.

2.  In-band signaling for MP LSPs

   Suppose an LSR, call it D, is attached to a network that is capable
   of MPLS multicast and IP multicast, and D has the desire to create IP
   multicast tree due to a certain IP multicast event, like a PIM Join,
   MSDP Source Announcement (SA) [RFC3618] [RFC3618], BGP Source Active auto-
   discovery route [I-D.rekhter-pim-sm-over-mldp] or RP discovery.
   Suppose that D can determine that the IP multicast tree needs to
   travel through the MPLS network until it reaches some other LSR, U.
   For instance, when D looks up the route to the Source or Rendezvous
   Point (RP) [RFC4601] of the IP multicast tree, it may discover that
   the route is a BGP route with U as the BGP next hop.  Then D may
   chose to set up a P2MP or MP2MP LSP, with U as root, and to make that
   LSP become part of the IP multicast distribution tree.  Note that
   other methods are possible to determine that an IP multicast tree is
   to be transported across an MPLS network using P2MP or MP2MP LSPs,
   these methods are outside the scope of this document.

   Source or RP addresses that are reachable in a VPN context are
   outside the scope of this document.

   Multicast groups that operate in PIM Dense-Mode are outside the scope
   of this document.

   In order to send transport the multicast stream tree via a P2MP or MP2MP LSP
   using in-band signaling the source and the group will be encoded into
   an mLDP opaque TLV encoding [I-D.ietf-mpls-ldp-p2mp].  The type of
   encoding depends on the IP version.  The tree type (P2MP or MP2MP)
   depends on whether this is a source specific or a bidirectional
   multicast stream. tree.  The root of the tree is the BGP next-hop that was
   found during the route lookup on the source or RP.  Using this
   information a mLDP FEC is created and the LSP is build towards the
   root of the LSP.

   When an LSR receives a label mapping or withdraw and discovers it is
   the root of the identified P2MP or MP2MP LSP, then the following
   procedure will be is executed.  If the opaque encoding of the FEC indicates
   this is an a Transit LSP (indicated by the opaque type), the opaque TLV will be
   is decoded and the multicast source and group is passed to the
   multicast code.  If the multicast tree information was is received via a
   label mapping, the multicast code will effectively
   treat this as a positif indication adds the downstream LDP
   neighbor to create a IP multicast tree
   based on the received information. olist of the corresponding (S,G) or (*,G) state,
   creating such state if it does not already exist.  If it was is due to a
   label withdraw, the multicast code will effectively treat this as having
   received a negative indication and it will remove the tree
   indentified by downstream LDP
   neighbor from the encoded information. olist of the corresponding (S,G) or (*,G) state.
   From this point on normal PIM processing will occur.

2.1.  Transiting Unidirectional IP multicast Shared Trees

   Nothing prevents PIM shared trees, used by PIM-SM in the ASM service
   model, from being transported across a MPLS core.  However, it is not
   possible to prune individual sources from the shared tree without the
   use of an additional out-of-band signaling protocol, like PIM or BGP
   [I-D.rekhter-pim-sm-over-mldp].  For that reason transiting Shared
   Trees across a Transit LSP is outside the scope of this draft.

2.2.  Transiting IP multicast source trees

   IP multicast source trees can either be created via PIM operating in
   SSM mode [RFC4607] or ASM mode [RFC4601] (for example via last hop
   behavior or MSDP [RFC3618]) and MUST be transporting across [RFC4601].  When PIM-SM is used in ASM
   mode, the MPLS
   network using a P2MP LSP.  A Transit LSP may be setup usual means of discovering active sources is to forward the
   IP multicast traffic join a
   sparse mode shared tree.  However, this document does not provide any
   method of transporting a sparse mode shared tree across an MPLS core.  If
   network.  To apply the multicast source technique of this document to PIM-SM in ASM
   mode, there must be some other means of discovering the active
   sources.  One possible means is
   reachable the use of MSDP [RFC3618].  Another
   possible means is to use BGP Source Active auto-discovery routes, as
   documented in [I-D.rekhter-pim-sm-over-mldp].  However, the method of
   discovering the active sources is outside the scope of this document,
   and as a global table result this document does not specify everything that is
   needed to support the ASM service model using in-band signaling.

   The source and group addresses are encoded into the a transit TLV.  Depending on the IP version it is
   either TLV as
   specified in Section 3.1 or and Section 3.2.

2.2.

2.3.  Transiting IP multicast bidirectional trees

   Bidirectional IP multicast trees [RFC5015] MUST be transported across
   a MPLS network using MP2MP LSPs.  A bidirectional tree does not have
   a specific source address; only the group address and address, subnet mask and RP are
   relevant for multicast forwarding.  This document does not provide
   procedures to discover RP to group mappings dynamically across an
   MPLS network and assumes the RP is statically defined.  Support of
   dynamic RP mappings in combination with in-band signaling is outside
   the scope of his document.

   The RP for the group already
   known by IP multicast is used to select the ingress PE and root of the
   LSP.  The group address is encoded in either according to the rules of
   Section 3.3 or Section 3.4, depending on the IP version.  The subnet
   mask associated with the bidirectional group is encoded in the
   Transit TLV.  There are two types of bidirection bidirectional states in IP
   multicast, the group specific state and the RPA state.  The first
   type is typlically typically created due to receiving a PIM join and has a
   subnet mask of 32 for IPv4 and 128 for IPv6, the IPv6.  The latter is typically
   created via the static RP mapping protocol and has a variable subnet mask.
   The RPA state is used to build a tree to the RP and used for sender
   only branches.  Each state (group specific and RPA state) will result
   in a separate MP2MP LSP.  The merging of the two MP2MP LSPs will be
   done by PIM on the root LSR.  No speccial procedures are nessesary
   for PIM to merge the two LSPs, each LSP is effectively treated as a
   PIM enabled interface.  Please see [RFC5015] for more details.

2.3.  Transiting IP multicast shared Trees

   Nothing prevents PIM shared trees from being transported across

   In order transport the packets of sender only branch to the root of
   the LSP a
   MPLS core.  However, it MP2MP is not possible created.  This will cause the sender only branches
   to prune receive each others packets.  These packets will be dropped and
   not forwarded, if that affect is undesireable some other means of individual
   sources from the shared tree without
   transport has to be established to forward packets to the use root of an additional out-of-
   band signaling protocol, the
   tree, like PIM.  For that reason transiting Shared
   Trees across a Transit Multi-Point to Point LSP is outside for example.  A technique to
   unicast packets to the scope root of this draft. a P2MP or MP2MP LSP is documented in

   [I-D.rosen-l3vpn-mvpn-mspmsi] section 3.2.2.1 and
   [I-D.ietf-mpls-ldp-p2mp] section 3.

3.  LSP opaque encodings

   This section documents the different transit opaque encodings.

3.1.  Transit IPv4 Source TLV

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type          | Length                        | Source
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                     | Group
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  2 (to be assigned by IANA).

   Length:  8

   Source:  IPv4 multicast source address, 4 octets.

   Group:  IPv4 multicast group address, 4 octets.

3.2.  Transit IPv6 Source TLV

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type          | Length                        | Source        ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                                               | Group         ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  3 (to be assigned by IANA).

   Length:  32

   Source:  IPv6 multicast source address, 16 octets.

   Group:  IPv6 multicast group address, 16 octets.

3.3.  Transit IPv4 bidir TLV

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type          | Length                        | Mask Len      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              RP                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Group                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  4 (to be assigned by IANA).

   Length:  9

   Mask Len:  The number of contiguous one bits that are left justified
      and used as a mask, 1 octet.

   RP:  Rendezvous Point (RP) IPv4 address used for encoded Group, 4
      octets.

   Group:  IPv4 multicast group address, 4 octets.

3.4.  Transit IPv6 bidir TLV
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type          | Length                        | Mask Len      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             RP                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Group                              ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  4 (to be assigned by IANA).

   Length:  33

   Mask Len:  The number of contiguous one bits that are left justified
      and used as a mask, 1 octet.

   RP:  Rendezvous Point (RP) IPv6 address used for encoded group, 16
      octets.

   Group:  IPv6 multicast group address, 16 octets.

4.  Security Considerations

   The same security considerations apply as for the base LDP
   specification, as described in [RFC5036].

5.  IANA considerations

   This document requires allocation from the LDP MP Opaque Value
   Element type name space managed by IANA.  The values requested are:

      Transit IPv4 Source TLV type - requested 2

      Transit IPv6 Source TLV type - requested 3
      Transit IPv4 Bidir TLV type - requested 4

      Transit IPv6 Bidir TLV type - requested 5

6.  Acknowledgments

   Thanks to Eric Rosen for his valuable comments on this draft.  Also
   thanks to Yakov Rekhter, Adrial Farrel and Uwe Joorde for providing
   comments on this draft.

7.  Contributing authors

   Below is a list of the contributing authors in alphabetical order:

     Toerless Eckert
     Cisco Systems, Inc.
     170 Tasman Drive
     San Jose, CA, 95134
     USA
     E-mail: eckert@cisco.com

     Nicolai Leymann
     Deutsche Telekom
     Winterfeldtstrasse 21
     Berlin, 10781
     Germany
     E-mail: n.leymann@telekom.de

     Maria Napierala
     AT&T Labs
     200 Laurel Avenue
     Middletown, NJ 07748
     USA
     E-mail: mnapierala@att.com

     IJsbrand Wijnands
     Cisco Systems, Inc.
     De kleetlaan 6a
     1831 Diegem
     Belgium
     E-mail: ice@cisco.com

8.  References

8.1.  Normative References

   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.

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

   [I-D.ietf-mpls-ldp-p2mp]
              Minei, I., Kompella, K., Wijnands, I., and B. Thomas,
              "Label Distribution Protocol Extensions for
              Point-to-Multipoint Point-to-
              Multipoint and Multipoint-to-Multipoint Label Switched
              Paths", draft-ietf-mpls-ldp-p2mp-05 draft-ietf-mpls-ldp-p2mp-08 (work in progress), June 2008.
              October 2009.

8.2.  Informative References

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

   [RFC5015]  Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
              "Bidirectional Protocol Independent Multicast (BIDIR-
              PIM)", RFC 5015, October 2007.

   [RFC3618]  Fenner, B. and D. Meyer, "Multicast Source Discovery
              Protocol (MSDP)", RFC 3618, October 2003.

   [I-D.ietf-l3vpn-2547bis-mcast]
              Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y.,
              Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in
              MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-07 draft-ietf-l3vpn-2547bis-mcast-10 (work
              in progress), July 2008. January 2010.

   [I-D.rekhter-pim-sm-over-mldp]
              Rekhter, Y. and R. Aggarwal, "Carrying PIM-SM in ASM mode
              Trees over P2MP mLDP LSPs",
              draft-rekhter-pim-sm-over-mldp-00 (work in progress),
              November 2009.

   [I-D.rosen-l3vpn-mvpn-mspmsi]
              Boers, A., Cai, Y., Napierala, M., Rosen, E., and I.
              Wijnands, "MVPN: Optimized use of PIM via MS-PMSIs",
              draft-rosen-l3vpn-mvpn-mspmsi-06 (work in progress),
              February 2010.

Authors' Addresses

   IJsbrand Wijnands
   Cisco Systems, Inc.
   De kleetlaan 6a
   Diegem  1831
   Belgium

   Email: ice@cisco.com

   Toerless Eckert
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose  CA, 95134
   USA

   Email: eckert@cisco.com

   Nicolai Leymann
   Deutsche Telekom
   Winterfeldtstrasse 21
   Berlin  10781
   Germany

   Email: nicolai.leymann@t-systems.com

   Maria Napierala
   AT&T Labs
   200 Laurel Avenue
   Middletown  NJ 07748
   USA

   Email: mnapierala@att.com