Subject: Re: Question on draft-wu-mpls-multicast-te-00.txt

From: Ben Abarbanel <[email-masked]>
Date: Thu, 17 Jun 1999 14:41:18 -0400

Bora Akyol wrote:

> The point that you are missing is the fact that the point-to-point MPLS
> tunnels implement an arbitrary IP topology that includes multicast traffic.
> The MPLS topology of the network is optimized according to the traffic that
> runs on top of the physical links including IP multicast. Therefore one does
> not need to add an MPLS multicast tree.
>
> I believe that this draft confuses MPLS multicast with IP multicast while
> implying that one needs to build an MPLS multicast tree to efficiently
> perform IP multicast which is untrue. MPLS tunnels when designed take into
> account IP multicast traffic as well.

Perhaps multicast traffic can be traffic engineered over the point to point MPLS
tunnels to be
regulated as to traffic type of service (QOS). This should solve the traffic
congestion issue being addressed in this spec.

Even intermediate nodes that makeup the point to point MPLS tunnels are not
aware of multicast addresses/routes. So that is covered sufficient enough to not
require the multicast
tree contstruction in the transit (core) network.

Regards,
Ben

>
>
> Regards
>
> Bora
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf
> > Of LiWen Wu
> > Sent: Thursday, June 17, 1999 10:57 AM
> > To: Bora Akyol
> > Cc: liwen wu; [email-masked]; [email-masked]; [email-masked]
> > Subject: Re: Question on draft-wu-mpls-multicast-te-00.txt
> >
> >
> > Bora Akyol wrote:
> >
> > > Comments:
> > >
> > > 1) Is the multicast traffic included in the statistics that are used to
> > > create the traffic matrix which in turn is used to create the
> > desired MPLS
> > > topology?
> >
> > Yes. But as  I am aware of today, all traffic engineereing
> > related drafts only
> > deal with
> > point-to-point MPLS tunnel.
> >
> > This paper propose building a point-to-multipoint MPLS tree to carry the
> > multicast traffic through the core network.
> >
> > These trees are traffic engineered to avoid congested node and
> > links . They
> > also can be engineered to meet certain QOS requirement.
> >
> > There is another big advantage by using this concept that:
> >
> > 1)  All the routers inside a core ISP domain DOES NOT need to be
> > aware of all the multicast groups and sources. (Similar to a core router
> > only aware of OSPF routes, but does not need to know all the BGP routes)
> >
> > 2) Only border routers(root and receivers) need to know all the
> > multicast groups and sources , mappings from multicast group and sources
> > to MPLS point-to-multipoint TREEs.
> >
> > best regards,
> > Liwen--
> >
> > >
> > >
> > > If the answer to this is *yes*, then ordinary traffic engineering will
> > > optimize the traffic flows such that you will *get* a good
> > distribution of
> > > the multicast flows over the existing physical topology. So the
> > procedures
> > > proposed in this draft are not needed.
> > >
> > > If the answer is *no* then the solution may be covered in this draft.
> > >
> > > I personally don't see a need for this draft or the methods
> > proposed in it.
> > > In most cases, the traffic matrix will actually include the multicast
> > > traffic and will optimize the MPLS topology accordingly.
> > Otherwise, you will
> > > end up with one multicast topology and one unicast topology and
> > yet another
> > > network to manage.
> > >
> > > If we want to make multicast routing more efficient, we should
> > follow along
> > > the lines **-omp drafts and create a multicast routing
> > algorithm that runs
> > > within an area and
> > > is sensitive to network utilization.
> > >
> > > Bora
> >
> > --
> > --------------------------------------------------------------------------
> > Liwen Wu                                     Phone: (703) 724-2619
> > Alcatel U.S.A                                FAX:   (703) 724-2005
> > 44983 Knoll Square                  Inet:  [email-masked]
> > Ashburn, Va. 20147
> > USA
> > ------------------------------------------------------------------
> > ----------
> >
> >
> >
> >

---

From: LiWen Wu <[email-masked]>
Date: Thu, 17 Jun 1999 13:56:37 -0400

Bora Akyol wrote:

> create the traffic matrix which in turn is used to create the desired MPLS
> topology?

Yes. But as  I am aware of today, all traffic engineereing related drafts only
deal with
point-to-point MPLS tunnel.

These trees are traffic engineered to avoid congested node and links . They
also can be engineered to meet certain QOS requirement.

best regards,
Liwen--

> optimize the traffic flows such that you will *get* a good distribution of
> the multicast flows over the existing physical topology. So the procedures
> I personally don't see a need for this draft or the methods proposed in it.
> traffic and will optimize the MPLS topology accordingly. Otherwise, you will
> end up with one multicast topology and one unicast topology and yet another
> network to manage.
>
> If we want to make multicast routing more efficient, we should follow along
> the lines **-omp drafts and create a multicast routing algorithm that runs
> within an area and

----------------------------------------------------------------------------

---

From: LiWen Wu <[email-masked]>
Date: Thu, 17 Jun 1999 14:28:08 -0400

> not need to add an MPLS multicast tree.

Bora, I agree with you that you could use point-to-point tunnel to carry
multicast traffic. Similarily, I could  also argue why not duplicate the packet
at source
and unicast them  one by one to all the receivers.

But I would think sending a packet through a point-to-multipoint tree is more
efficient than duplicating the packet at ingress and send them through the
MULTIPLE point-to-point MPLS tunnels.

> account IP multicast traffic as well.

This draft provides only ONE method on how to manage multicast traffic
in a core network.  It proposes using MPLS point-to-multipoint tree
to transport multicast traffic through a core ISP network.

best regars,
Liwen--

---

From: Bora Akyol <[email-masked]>
Date: Thu, 17 Jun 1999 11:06:10 -0700

Regards

Bora

---

From: Ben Abarbanel <[email-masked]>
Date: Thu, 17 Jun 1999 16:25:08 -0400

> MULTIPLE point-to-point MPLS tunnels.

Bora, Liwen:
  One additional improvement I see by this design approach, is that with a point to
multipoint multicast tree structure. All nodes are MPLS capable and know at time of
tunnel creation where the juncture at which packets are to be broadcast to EGRESS
points. This implies that we never leave level 2 processing during multicast packet
forwardin thru the point to multipoint tunnels. In a similar topology without a
braodcast label swapping function, we would have to leave level 2 to enter level 3
forwarding to do a multicast forwarding lookup function to seek the individual
egress tunnels and reenter level 2 label switching again. As shown below.

                                 Multicast Tree Point to Multipoint forwarding

                                                                     |  Ingress
Point (level 3 to level 2 transitioning)
                                                             SRC RTR
                                                                     |
                                                                     |     Label
Switching (level 2)
                                                                     |
                                                          JUNCTURE RTR
                                                                 /    |    \
                                                               /      |      \
Broadcast Label Switching  (level 2)
                                                             /        |        \
                                                        dst1    dst2     dst3
(Egress points) (transition to level 3)

                                 Conventional  Point to Point Multicast Forwarding

                                                                     |  Ingress
Point (level 3 to level 2 transitioning)
                                                             SRC RTR
                                                                     |
                                                                     |     Label
Switching (level 2)
                                                                     |
                                                          JUNCTURE RTR  (transition
to level 3 to do multicast lookup)
                                                                 /    |    \
(then broadcast to individual tunnels at level 2)
                                                               /      |      \
Label Switching again (level 2)
                                                             /        |        \
                                                        dst1    dst2     dst3
(Egress Point) (transition to level 3)

     Regards,
     Ben

---

From: Bala Rajagopalan <[email-masked]>
Date: Thu, 17 Jun 1999 17:13:40 -0400

Bora Akyol wrote:

> Liwen,
>
> Let me try explaing this again:
>
> 1. There is an IP network consisting of N nodes (N>=2).
> 2. There is an MPLS topology over which the IP packets flow over including
> multicast packets.
> 3. There is a statistics collection process that collects a traffic matrix
> (NxN) for all of IP traffic that is flowing between the nodes of an area
> like you will find in a backbone topology.
> 4. The optimization process uses 1 and 3 to produce 2 and in the meantime
> configures the network such that all data flow demands are satisfied
> optimally (including MPLS packets).

What's not clear to me is how you'd implement (4). I assume that
you're suggesting that
the MPLS topology has been constructed to take into account some coarse
estimate of the multicast demands. Now, you still have to ensure that the
multicast (and unicast) paths in the network for the data packets are as
intended.

I would take Wu's draft as proposing a mechanism for actually establishing
specific
paths for multicast (which perhaps were derived in step (4) above).

>
>
> Moreover, as multicast traffic is dynamic and can change rapidly, I don't
> see the point of *multicast* traffic engineering which is assumed to be
> quasi-static.

I agree with this. But the assumption of dynamism also works against your steps
for traffic engineering (steps 1-4 above), since you have also assumed that
multicast traffic can be estimated meaningfully for  input to the topology
design process (in step 3).

Regards,

--

Bala Rajagopalan
NEC USA, C&C Research Labs
4 Independence Way
Princeton, NJ 08540
U.S.A

Ph: +1-609-951-2969
Fax: +1-609-951-2499
Email: [email-masked]

---

From: LiWen Wu <[email-masked]>
Date: Thu, 17 Jun 1999 16:36:10 -0400

Hello Bora,

   Let me try to explain with one following simple example:

A--->B---->C
                |
                D---->E

A,C,E are border routers, B,D are core routers.

I could build:

1) Tunnel 1- {A,B,C} to carry the unicast traffic
which enters the network from A and exit the
network through C

2) Tunnel 2 - {A,B,D,E} to carry the  unicast traffic
which enters the network  from A and exit the
network through E

3) Tree1 - {A,{B, C}, {B,D,E}} to carry the multicast traffic
which enters the network from A and exit the
network through C and E.

For a multicast flow which enters the network from A and
exits from the network through E and C, I would think
put it through Tree1 is more efficient than
duplicate it at A and sent them through Tunnel1 and Tunnel2.

best regards,
Liwen--

Bora Akyol wrote:

> What is being suggested in this draft results in another version of the MPLS
> topology in addition to (2) but in fact it does *NOT* optimize significantly
> better than the current traffic engineering approaches but results in two
> (overlay) networks.
>
> Nowhere in my email, do I suggest that you abandon IP level multicast and
> use unicast, so I don't understand the last comment that you are making.
> What I am suggesting is that IP Multicast traffic can flow over the traffic
> engineered network just as well as the unicast traffic. This is *especially*
> true in a backbone network.
>
> What this ID sounds like is a way of doing MPLS multicast as you would see
> in an ATM network which is fine, but is not related to traffic engineering.
>
> Regards
>
> Bora
>
> > Sent: Thursday, June 17, 1999 11:28 AM
> > To: Bora Akyol
> > > > From: [email-masked]
> > [mailto:[email-masked]]On Behalf
> > > > Of LiWen Wu

---

From: Bora Akyol <[email-masked]>
Date: Thu, 17 Jun 1999 12:39:57 -0700

Liwen,

Regards

Bora

---

From: Bora Akyol <[email-masked]>
Date: Thu, 17 Jun 1999 14:13:14 -0700

There are some comments later in this email, but I believe that this ID is
trying to address the following:

1) How to do multicast in MPLS networks.
2) How to provide QoS to an aggregated set of multicast flows. (Why not use
Diffserv PHBs)

This ID should solve both (1) and (2) but it solves (1) and does not show
*how* multicast flows are aggregated into a small number of MPLS multicast
trees. Moreover, MPLS being designed for tag switching does not provide a
natural method or representation for multicast.

Finally, a multicast routing algorithm such as PIM or a new one (that is
network utilization sensitive) can achieve (2) when Diffserv marking is used
thereby pre-empting the need to do 1.

Now specific comments:
----------------------

If B&D are core routers  and A,C and E are border routers than one would
assume that they have direct connectivity.
So the picture would look like:

---B----D
  / \    \
 A  C     E

If a multicast packet is traversing the network as you mention, I would
agree with you that the multicast scheme is more efficient, but, this is
solving the MPLS multicast problem not a traffic engineering problem. The
efficiency is not a property associated with traffic engineering but in
general associated with multicast.

In this case, it is much easier to let IP routers do **routing** and not
associate the multicast with MPLS tunnels. As an added bonus you have only
one multicast routing algorithm to use instead of an IP and an MPLS
algorithm.

Again, multicast is dynamic and should not be associated with MPLS tunnels
which are intended for quasi-static situations.

Finally, maybe the title of the ID should be changed to:

Multicast in MPLS networks

Thanks

Bora

> Sent: Thursday, June 17, 1999 1:36 PM
> To: Bora Akyol
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: Bora Akyol <[email-masked]>
Date: Thu, 17 Jun 1999 16:07:52 -0700

That is a primary purpose of having an MPLS-based network.
You may want to check out the slides from MPLS' 98 workshop.

You can the statistics by the LSP groups that are going between the border
LSRs in a traffic-engineered MPLS network.

Regards

Bora

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Indra
> Widjaja
> Sent: Thursday, June 17, 1999 4:01 PM
> To: Bora Akyol
> Cc: LiWen Wu; [email-masked]; [email-masked]; [email-masked]
> Bora:
> If I understand your point on number 3, you assume that you can
> collect the
> current
> traffic statistics for every ingress-egress pair (for a given class of
> service).
> How do you propose to do this?
>
> indra
>
>
> >

---

From: Bora Akyol <[email-masked]>
Date: Thu, 17 Jun 1999 16:36:13 -0700

In a backbone traffic engineered network, my assumption was that
there are only explicitly routed LSPs so my statement is correct if this
assumption is satisfied.

Anyone planning on running plain LDP in the backbone in addition to RSVP or
CR-LDP?

Bora

> From: Indra Widjaja [mailto:[email-masked]]On Behalf Of
> Indra Widjaja
> Sent: Thursday, June 17, 1999 4:30 PM
> To: Bora Akyol
> I was in that workshop and was not aware about any credible discussion
> pertaining to
> traffic matrix collection.
>
> >
> >
> If you only collect the statistics on traffic engineered LSPs
> between border
> LSRs, then you
> won't see the whole picture (i.e., you won't be able to build the
> NxN traffic
> matrix) since
> there are other traffic flows (e.g., the ones that go through
> hop-by-hop LSPs).
>
> The problem is further compounded if you need to build a traffic
> matrix for
> each class.
>
> indra
>
>
> >
> >
> > Regards
> >
> > Bora
> >

---

From: Indra Widjaja <[email-masked]>
Date: Thu, 17 Jun 1999 19:01:12 -0400

> like you will find in a backbone topology.

Bora:
If I understand your point on number 3, you assume that you can collect the
current
traffic statistics for every ingress-egress pair (for a given class of
service).
How do you propose to do this?

indra

---

From: [email-masked]
Date: Thu, 17 Jun 1999 19:25:20 -0400

Since you know that, so Can you share it with us ? Can you tell us a
little bit more on this ? I did not quite understand your last message

thank you,
Alex Mondrus

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 18 Jun 99 8:33:00 JST

Bala;

> What's not clear to me is how you'd implement (4).

????

3 is already wrong.

If it is multicast, the traffic matrix is (Nx2^(N-1)), which is
the number of labels required for MPLS.

That is, multicast with MPLS is with more than 20 nodes is nothing
more than a silly joke.

But, it is not a problem, because best effort unicast MPLS is a
silly joke from the beginning.

							Masataka Ohta

---

From: Indra Widjaja <[email-masked]>
Date: Thu, 17 Jun 1999 19:29:30 -0400

> LSRs in a traffic-engineered MPLS network.

If you only collect the statistics on traffic engineered LSPs between border
LSRs, then you
won't see the whole picture (i.e., you won't be able to build the NxN traffic
matrix) since
there are other traffic flows (e.g., the ones that go through hop-by-hop LSPs).

The problem is further compounded if you need to build a traffic matrix for
each class.

indra

---

From: LIWEN WU <[email-masked]>
Date: Thu, 17 Jun 1999 23:01:10 -0400

Hello Bora,

  Please see my comments belows:

Best regards,
Liwen--

> 1) How to do multicast in MPLS networks.
Yes, this draft propose one alternative on how to transport multicast 
traffic efficiently through a core ISP MPLS capable network.

> 2) How to provide QoS to an aggregated set of multicast flows. (Why not use
Yes, a point-to-multipoint tree can be used to carry an aggregated set
of multicast flow with certain QoS constraints.

DiffServ PHB(Per-Hop-Behavior) defines how a packet can be handle by 
a SINGLE node.

This draft describe one method on how a multicast packet can be handled
by a network. It proposes to 1) build a traffic engineering
point-to-multipoint tree
and 2) then tunnel this multicast packet through this
point-to-multipoint tree.
This point-to-multipoint tree is built to avoid congested nodes
and links, and it is also built to meet certain QoS constraint. 

> trees. 
Similar to unicast traffic engineering, the mapping of a multicast flow
to a MPLS multicast tree (tunnel in unicast) is a local policy decision
of the
root router (or ingress router in unicast).

It can be a result of a multicast traffic related SLS(Service Level
Specification) between the core network and their neighbor networks. It
can also be
a result of inter-domain routing protocols(MBGP/MSDP, BGMP) running at
all the border
routers. I agree with you that they are important. But I would think
they should
be addressed in a different document.

Moreover, MPLS being designed for tag switching does not provide a
> thereby pre-empting the need to do 1.

Here are a couple of advantages if MPLS tree is used:
1) The core router B,D are not required to know every internet-wide
multicast
groups and sources.

2) The MPLS tree can be traffic engineered(built) to avoid congested
node 
and links. 

3) If a set of multicast flows share the same ingress root and same set
of
egress  node(leafs), they can be tunnelled through a single
point-to-multipoint
tree. This way,the multicast tree states at core router B and D are 
signaficantly reduced.

best regards,
Liwen--

---

From: Kenneth CARLBERG <[email-masked]>
Date: Fri, 18 Jun 1999 10:01:37 +0100

> Moreover, as multicast traffic is dynamic and can change rapidly, 

yes, but "can" does not equate to all -- meaning that both static and 
dynamic spectrums need to be addressed.  there are probably others on 
the rem-conf list that can provide a wider set of examples, but last 
november, i took some samplings of a shuttle mission and if memory 
serves me correctly, nearly 20% of the total number of receivers were 
members of the group for a 24 hour period.  and yes, if you reply that 
mbone info is not a real reflection of the internet or mcast-like traffic 
(in production nets), then consider when single-source TV is eventually 
added to the net.

> I don't

perhaps it depends on what one considers important in the area of traffic
enginnering.  traditional items for big-time ISPs focus on load 
concentrations.
but in putting on my 'industry' hat on, i get periodic questions regarding 
dual-homed or multi-access systems that involve combinations of geo/leo 
satcom and terestrial connectivity....begging for a reasonable means of 
having
control in how the branch is grated onto a tree.

-ken

---

From: Bradley Reynolds <[email-masked]>
Date: Fri, 18 Jun 1999 08:02:54 -0400 (EDT)

> enginnering.  traditional items for big-time ISPs focus on load 

perhaps big-time ISPs will be more apt to concentrate on multicast
traffic engineering when it equates to more than .1% of their aggregate
traffic.  

BR

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 18 Jun 1999 13:06:42 +0100

In message <[email-masked]>, Bradley

 >>traffic engineering when it equates to more than .1% of their aggregate
 
perhaps if they used multicast for cache/mirror prefetch and streaming
then multicast would amount to 40% of the backbone traffic, but 
the backbone would be running at 20% lighter load...:-)

 cheers

   jon

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 18 Jun 1999 13:20:51 +0100 (BST)

On Fri, 18 Jun 1999, Jon Crowcroft wrote:

>  Bradley Reynolds typed:

If more people ran Squid with multicast ICP, this might happen.

http://squid.nlanr.net/Squid/FAQ/FAQ-13.html

oh look, they've made multicast question number thirteen. Why could
that possibly be?

L.

traditional items for big-time ISPs focus on billing. Or used to.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>