Internet Draft
Network Working Group                          Liwen Wu, Pierrick Cheval
Internet Draft                                   Dirk Ooms, Alex Mondrus
Expiration Date: December 1999                                  Alcatel

                                                              June 1999


                   MPLS Multicast Traffic Engineering
                     draft-wu-mpls-multicast-te-00.txt


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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.

   To view the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
   Directory, see http://www.ietf.org/shadow.html.

Abstract

   In a core ISP backbone network, when there are a lot of multicast
   traffic which belongs to huge number of multicast groups, providing
   differentiated services to different kind of multicast traffic
   through this core network becomes a very difficult task. Also, how to
   use network resources in an efficient and optimized way to support
   differentiated multicast service is very difficult.

   This draft introduces one method, MPLS multicast traffic engineering,
   which can be used to manage multicast traffic in a core ISP backbone
   network.

   This draft starts with introducing the MPLS multicast traffic
   engineering concept. Then it describes 2 ways of building a multicast
   traffic engineering tree: sender-initiated tree and receiver-
   initiated tree. Finally, it provides an appendix, which defines the
   extensions to CR-LDP to support MPLS multicast traffic engineering.

1. Introduction



Wu, et al.                                                      [Page 1]





Internet Draft     MPLS Multicast Traffic Engineering         June 1999


   If a core ISP backbone network wants to provide differentiated
   multicast services, the constructed multicast trees must not include
   highly congested nodes or links.

   Similar to unicast traffic engineering[MPLS-TE], an MPLS multicast
   tree(or a point-to-multipoint tunnel) can be built in a network to
   carry multicast traffic. This tree can be administratively specified,
   or automatically computed by a suitable entity based on QoS and
   policy requirements, taking into consideration the prevailing network
   state.

   Let's assume the following scenario. An IP network consists of four
   IP devices, device e1, e2, e3, e4 and some other nodes.  A network
   administrator, for some reason, made a decision that e1 will become
   the root of the tree. The network administrator requests devices
   e2,e3, e4 to compute the reverse path(source-route) to e1. The
   reverse path (source-route) is calculated from the Constraint
   Routed(CR) topology database. Since the reverse path from e1 to e2,e3
   and e4 are calculated based on the CR topology, there is much less
   chance that routes from e1 to e2,e3 and e4 will be congested. So, a
   MPLS signaling protocol using the calculated source-routing
   information sets up a MPLS point-to-multipoint tree from e1 to e2,e3
   and e4.

   When a multicast packet arrives at the root of an MPLS multicast
   tree, after the classification, an MPLS label is imposed to the
   packet. Then, at the subsequent hops, the LSR looks up the forwarding
   table with the incoming label, finds out all the downstream routers
   and corresponding outgoing labels, makes the replications, and
   forwards them to the downstream routers with the outgoing labels.

   Since the traffic that flows along a label-switched tree is defined
   by the label applied at the ingress node(or root) of the MPLS tree,
   these trees can be regarded as tree tunnels.  When an MPLS tree is
   used in this way we refer to it as an MPLS tree tunnel.

   MPLS tree tunnels allow the implementation of a variety of policies
   related to network performance optimization.  For example, MPLS tree
   tunnels can be automatically or manually routed away from network
   failures, congestion, and bottlenecks.

   The mechanism in this draft constructs multicast trees immediately on
   L2.  Thus the mapping of L3 trees onto L2, as described in [MPLS-MC],
   is not needed here.

   The MPLS tree tunnel can be built as a result of a multicast SLA
   between a core network and its access network, or dynamic
   JOIN/PRUNE[PIM] from the access network. The actual mechanisms,



Wu, et al.                                                      [Page 2]





Internet Draft     MPLS Multicast Traffic Engineering         June 1999


   processes, and algorithms used to trigger and compute explicitly
   routed trees are beyond the scope of this specification.

   The MPLS tree tunnel concept proposed in the draft applies to a core
   network model. It does not apply to the end-host workstation.

1.1 Dependencies on CR-IGP

   In the case of automatic tree building, an IGP is needed.  Both, OSPF
   [CR-OSPF] and IS-IS [CR-ISIS] can be used for this purpose. The LSA
   information is flooded throughout an AS, the point-to-multipoint tree
   is calculated based on the pruned CR topology.

   In the case of manual tree building, it is assumed that a network
   administrator provisions the CR routing paths and it is assumed that
   the network operator knows his network topology. Based on this CR
   routing information the point-to-multipoint tree can be calculated.
   Therefore, the tree is always using the CR topology and the tree is
   not congested.

   It is good to point out here that this document assumes that an IGP
   detects bottlenecks and the multicast tree is built on the pruned,
   excluding bottlenecks, topology.

   We would like to stress the important role of IGPs for Multicast
   Traffic Engineering. IGPs should be able to convey specific multicast
   information. Since this document concentrates on Multicast Traffic
   engineering, new extensions for IGPs are needed, but they are out of
   the scope of this document.

   Also, we would like to emphasize that the proposed technique is
   relatively simple and relies on existing routing and signalling
   protocols.

1.2 Interworking with other multicast routing protocols.

   The method we describ in the draft only applies to a single
   administrative domain(AS).

   We assume that the root and receivers (border routers) of the point-
   to-multipoint tree are running some kind of inter-domain multicast
   protocol, such as MBGP/BGMP or MBGP/MSDP. These inter-domain
   multicast protocols are used to pull the multicast traffic into the
   domain and also send them out to the downstream domains.

2. Sender-Initiated Multicast Traffic Engineering Tree

   A sender-initiated multicast traffic engineering tree, which is one



Wu, et al.                                                      [Page 3]





Internet Draft     MPLS Multicast Traffic Engineering         June 1999


   of the applications mentioned in[EXPLICIT_TREE],  is a tree built
   from root to all the receivers. This tree can be centrally calculated
   by an NMS station and sent over to the root, or it can be a tree
   calculated by the root of the tree.

   The tree can be setup by extending CR-LDP. A new CR-LDP object,
   explicit tree object, can be defined to represent the whole multicast
   tree. The root of the tree sends a label request along with the
   explicit tree object. The subsequent LSR looks up its downstream
   routers in the explicit tree object of the label request msg. Then it
   sends the label request to these downstream routers. After the router
   receives the label mapping msgs from all of the downstream routers,
   it allocates a label, puts this point-to-multipoint MPLS forwarding
   entry into the forwarding table and sends a label mapping msg to its
   upstream router.

   Given that this style of tree creation must carry all of the elements
   of the entire tree in the initial label request, and given that it is
   highly undesirable to fragment such requests, this style of tree
   building is primarily suited to trees with smaller numbers of
   receivers.

   If a root driven tree creation is desired for large trees, a
   mechanism will be needed by which the tree can be established in
   several separate requests.

   Setting up a sender-initiated tree which contains a large number of
   receivers and dynamic JOIN/PRUNE receivers is a subject for future
   study.

   This tree can be torn down by the Label Release msgs sent from the
   root to all the receivers. When a node receives a Label Release msg,
   it takes the MPLS forwarding entry out of the forwarding table, and
   sends a Label Release msg to every downstream routers.

3. Receiver-Initiated Multicast Traffic Engineering Tree

   A receiver-initiated multicast traffic engineering tree is a tree
   built from receivers to the root. The tree can be centrally
   calculated by an NMS station. The reverse path from receiver to root
   can also be calculated at the receiver of the tree.  The reverse path
   of the root to each receiver is sent to the receiver if it is
   calculated by an NMS station. And each receiver sends a CR-LDP JOIN
   with the explicit reverse path and an MPLS label towards the root. At
   the subsequent upstream router, it merges all the CR-LDP JOIN msgs of
   the same tree, allocates a label, puts the point-to-multipoint label
   forwarding entry into the forwarding table, and sends a CR-LDP JOIN
   with the newly allocated MPLS label and explicit reverse path object



Wu, et al.                                                      [Page 4]





Internet Draft     MPLS Multicast Traffic Engineering         June 1999


   to the upstream router.

   When a receiver wants to leave the group, it can send a Label
   Withdraw to its upstream router. When all the downstreams neighbors
   of a router leave the group, it should send a label withdraw to its
   upstream neighbor.

   When a CR-LDP JOIN reaches a on-tree router, the router processes the
   CR-LDP JOIN, modifies the forwarding entry with the label assigned by
   the newly joined downstream router and finishes the JOIN procedure.

   This method relies on CR IGP. Since this method is receiver-
   initiated, the point-to-multipoint tree is set up on demand.

   If we compare it with the sender-initiated tree approach, the
   receiver-initiated method is more flexible in adding and removing LSP
   branches. In the case of the sender-initiated approach, the source
   should be able to know all receivers, so if there is requirement for
   building a more static tree , then the sender-initiated approach may
   be chosen.

4. Security Considerations

   Security considerations will be addressed in a future revision of
   this document.

5. Acknowledgements

   The authors would like to acknowledge the helpful comments and
   suggestions of the following people: Joel M.Halpern, Cheng-Yin Lee.

6. Authors's Address

   Liwen Wu

     Alcatel
     44983 Knoll Square
     Ashburn, VA. 20147
     U.S.A
     Phone: 703-724-2619
     Email:liwen.wu@adn.alcatel.com

   Pierrick Cheval

     Alcatel
     44983 Knoll Square
     Ashburn, VA. 20147
     U.S.A



Wu, et al.                                                      [Page 5]





Internet Draft     MPLS Multicast Traffic Engineering         June 1999


     Phone: 703-724-2080
     Email:Pierrick.Cheval@adn.alcatel.com

   Alex Mondrus

     Alcatel
     44983 Knoll Square
     Ashburn, VA. 20147
     U.S.A
     Phone: 703-724-2749
     Email:alex.mondrus@adn.alcatel.com

   Dirk Ooms

     Alcatel Research
     Francis Wellesplein
     B-2018, Antwerp
     Belgium
     Phone: 32-3-240-4732
     Email:Dirk.Ooms@alcatel.bel

7. References

 [MPLS-MC]: "Framework for IP Multicast in MPLS", D.Ooms, et.al., work
 in progress, Internet Draft, <draft-ooms-mpls-multicast-02.txt>

 [MPLS-TE]: "Requirements for Traffic Engineering Over MPLS", Daniel O.
 Awduche, et.al., work in progress, Internet Draft 

 [EXPLCIT_TREE]: "Explicit Tree Routing", Heinrich Hummel,Swee Loke,
 work in progress, Internet Draft, 

 [CR-LDP]: "Constraint-Based LSP Set up Using LDP", Bilel Jamoussi,
 et.al., work in progress, Internet Draft, 

 [CR-OSPF]: "OSPF Extensions for Traffic Engineering", Derek M. Yeung,
 work in progress, Internet Draft, <draft-yeung-ospf-traffic-00.txt>

 [CR-ISIS]: "IS-IS extensions for Traffic Engineering", Henk Smit,
 et.al., work in progress, Internet Draft, 

 [PIM]: "Protocol Independent Multicast-Sparse Mode (PIM-SM)", D.
 Farinacci, et.al., RFC2362.




Wu, et al.                                                      [Page 6]





Internet Draft     MPLS Multicast Traffic Engineering         June 1999


Appendix A. Extensions for CR-LDP

A.1 MPLS Multicast Tree ID

   A MPLS multicast tree id is used to identify a network-wide unique
   multicast tree. The LSPID field can be used to represent the MPLS
   multicast tree id value.

   The semantics of LSPID is specified in [CR-LDP].

A.2 Explicit Tree Object(TREE-TLV)

   The TREE-TLV is an object that specifies the tree to be taken by the
   point-to-multipoint LSP being established. It is composed of one or
   more Explicit Tree Hop TLVs (TREE-Hop TLVs) defined in Section 4.2.1


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |U|F|         TREE  -TLV  (??)  |      Tree Size                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        TREE-Hop TLV 1                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        TREE-Hop TLV 2                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                          ............                         ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        TREE-Hop TLV n                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   U bit
     Unknown TLV bit. As defined in [LDP].

   F bit
     Forward unknown TLV bit.  As defined in [LDP].

   Type
     A two byte field carrying the value of the TREE-TLV type which is
     ??.

   Tree Length
     Specifies the number of the TREE-HOP objects in the tree.

   TREE-Hop TLVs
     One or more TREE-Hop TLVs defined in Section 4.2.

   The TREE-HOP objects are ordered as "depth-first-order" in the msg.



Wu, et al.                                                      [Page 7]





Internet Draft     MPLS Multicast Traffic Engineering         June 1999


   Here is one example:


               A
               |
       +-------+----------+
       |       |          |
       B       C          D
               |
          +----+------+
          |    |      |
          E    F      G

   The TREE-TLV are encoded as {A,B,C,E,F,G,D}

A.2.1 Tree-Hop TLV

   The TREE-HOP TLV is a object that is used to represent a node that is
   the part of the tree.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |U|F|         TREE-HOP-TLV  (??)  |      Sub Tree Size          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | TREE-Hop-Type                   |     Length                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|                                  Content //                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   U bit
     Unknown TLV bit. As defined in [LDP].

   F bit
     Forward unknown TLV bit.  As defined in [LDP].

   Type
     A two byte field carrying the value of the TREE-HOP-TLV type which
     is ??.

   Sub-Tree Size
     This field contains the number of TREE-HOP objects under this
     subtree.

   Tree-Hop Type
     A fourteen-bit field indicating the type of contents of Tree-Hop.
     Currently defined values are:



Wu, et al.                                                      [Page 8]





Internet Draft     MPLS Multicast Traffic Engineering         June 1999


             Value                   Type
             -----                   ------------------------
             0x801                   IPv4 address
             0x802                   IPv6 address

   Length
     Specifies the length of the value field in bytes.

   L bit
     The L bit is an attribute of the Tree-Hop. The L bit is set if the
     Tree-Hop represents a loose hop in the explicit reverse route. If
     the bit is not set, the Tree-Hop represents a strict hop in the
     explicit reverse route.

     The L bit in the Tree-Hop is a one-bit attribute.  If the L bit is
     set, then the value of the attribute is "loose."  Otherwise, the
     value of the attribute is "strict."  For brevity, we say that if
     the value of the Tree-Hop attribute is loose then it is a "loose
     Tree-Hop."  Otherwise, it's a "strict Tree-Hop.". Further, we say
     that the abstract node of a strict or loose Tree-Hop is a strict or
     a loose node, respectively.  Loose and strict nodes are always
     interpreted relative to their prior abstract nodes.

     The path between a strict node and its prior node MUST include only
     network nodes from the strict node and its prior abstract node.

     The path between a loose node and its prior node MAY include other
     network nodes which are not part of the strict node or its prior
     abstract node.

   Contents
     A variable length field containing the node or abstract node that
     is the consecutive nodes that make up the explicit routed LSP.

A.3 Label Request

   The label request described in [CR-LDP] is changed to carry TREE-TLV
   instread of ER-TLV. So the format of label request is as follows:


         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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |U|   Label Request (0x0401)   |      Message Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Message ID                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     FEC TLV                                   |



Wu, et al.                                                      [Page 9]





Internet Draft     MPLS Multicast Traffic Engineering         June 1999


       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Return Message ID TLV  (mandatory)        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     LSPID TLV            (CR-LDP, mandatory)  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     TREE-TLV             (CR-LDP, mandatory)  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Traffic  TLV         (CR-LDP, optional)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Pinning TLV          (CR-LDP, optional)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Resource Class TLV (CR-LDP, optional)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Pre-emption  TLV     (CR-LDP, optional)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




A.4 JOIN Msg

   The JOIN msg is sent from downstream routers towards to root to build
   a tree.

   The format of JOIN msg is as follows:

      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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |U|   JOIN                     |      Message Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Message ID                                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     FEC TLV                                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Return Message ID TLV  (mandatory)        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     LSPID TLV            (CR-LDP, mandatory)  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ER-TLV               (CR-LDP, mandatory)  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Traffic  TLV         (CR-LDP, optional)   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Resource Class TLV (CR-LDP, optional)     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Pre-emption  TLV     (CR-LDP, optional)   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Wu, et al.                                                     [Page 10]





Internet Draft     MPLS Multicast Traffic Engineering         June 1999


   Each node decides the upstream root according the value specified in
   ER-TLV.

















































Wu, et al.                                                     [Page 11]