The MPLS WG Archive

[Ajay Simha <asimha@cisco.com>]

On Sat, 15 Sep 2001, Pour, Mort wrote:

> Hi,
> I have some questions regariding this as well. All the attributes defined in
> 2702 are
> for traffic trunks. How can we establish traffic trunks with their
> attributes?
> Are they signaled? It seems to me that LSPs are what are signaled. But LSPs
> do not seem to have attributes.
> Also I hve not seen any reference in Juniper and Avici docs to traffic
> trunks.
> Is anybody using them?

Actually in most cases a traffic trunk becomes the tunnel OR LSP being used.

For example let us say we have a trunk that needs 60Mb of aggregate bandwidth.
We would specify this "attribute" of the trunk under the tunnel.  After it is
provisioned in such a way the following need to occur:

1. CSPF at headend - to see if this available

2. if CSPF succeeds - Path Setup would involved send RSVP (may be some message
in CR-LDP as well - I just know RSVP).

In RSVP the TSPEC would actually specify how much bandwidth is being
requested.  It can also carry the AFFINITY attribute of the trunk:

4.7. Session Attribute Object

   The Session  Attribute  Class  is  207.   Two  C_Types  are  defined,
   LSP_TUNNEL,   C-Type   =  7  and  LSP_TUNNEL_RA,  C-Type  =  1.   The
   LSP_TUNNEL_RA C-Type includes all the same fields as  the  LSP_TUNNEL
   C-Type.   Additionally it carries resource affinity information.  The
   formats are as follows:

from draft-ietf-mpls-rsvp-lsp-tunnel-09.txt

-ajay

 > Mort
> -----Original Message-----
> From: Ajay Simha [mailto:asimha@cisco.com]
> Sent: Saturday, September 15, 2001 9:34 AM
> To: Hemant P. Kelkar
> Cc: zhuheqing@huawei.com; mpls-ops@mplsrc.com; mpls@UU.NET
> Subject: Re:Re: Traffic Trunk?
>
>
> On Sat, 15 Sep 2001, Hemant P. Kelkar wrote:
>
> > Hi,
> > Sorry for jumping into the discussion, but I have few points related with
> > the traffic trunk.
> > Can we use the term "aggregate load" in conjunction with traffic trunk ?
> > Secondly, the amount of traffic can vary between two given points either
> > at POP or inside the core. How does one speifically defines traffic trunk
> > in view of the following :
>
> I would think that the traffic load does vary - hence the term "aggregate".
> > #1. Services
>
> A traffic trunk could be 1 service or many right?  For example you could
> have
> voice, data and video flowing from popA to popB over a trunk.  Or you could
> break them up into three trunks.
>
> > #2. Connections
>
> I think each connection could be seen as a trunk (without getting religious)
>
> > #3. Flows
>
> Many flows would constitue a trunk (in the real deployment context.  Of
> course
> in voice we have a voice trunk everytime I call you over the phone).
>
> > #4. Lifetime of a switched data path inside the network.
>
>
> I think it is more of "Traffic" characteristics we are talking about here
> rather than what path it takes.
>
> Rather than "interpretting the bible" :-)
>
> " A note on terminology: The concept of MPLS traffic trunks is used
> 	   extensively in the remainder of this document. According to Li
> and
>    Rekhter [3], a traffic trunk is an aggregation of traffic flows of
>    the same class which are placed inside a Label Switched Path.
>    Essentially, a traffic trunk is an abstract representation of traffic
>    to which specific characteristics can be associated. It is useful to
>    view traffic trunks as objects that can be routed; that is, the path
>    through which a traffic trunk traverses can be changed. In this
>    respect, traffic trunks are similar to virtual circuits in ATM and
>    Frame Relay networks.  It is important, however, to emphasize that
>    there is a fundamental distinction between a traffic trunk and the
>    path, and indeed the LSP, through which it traverses. An LSP is a
>    specification of the label switched path through which the traffic
>    traverses. In practice, the terms LSP and traffic trunk are often
>    used synonymously. Additional characteristics of traffic trunks as
>    used in this manuscript are summarized in section 5.0."
>
> RFC 2702.
>
> -ajay
>
> > --
> > Regards,
> > Hemant
> >
> > Date: Sat, 15 Sep 2001 09:01:41 -0400 (Eastern Daylight Time)
> > From: Ajay Simha <asimha@cisco.com>
> > To: Zhu Heqing <zhuheqing@huawei.com>
> > Cc: mpls@UU.NET
> > Subject: Re: Traffic Trunk?
> >
> > On Sat, 15 Sep 2001, Zhu Heqing wrote:
> >
> > > Hi, All:
> > >
> > > I am eager to know what's really meaning of "traffic trunk".
> > > In fact, it has been interpreted in RFC2702.(MPLS TE requirement).
> > > But I feel it is too abstract to get the point .
> > > What I can understand is to map FECs to LSPs directly.
> > > Maybe we can extend the routing protocol to use these LSPs.
> > > Can you give me a specific example or more specific description?
> >
> > I would simply define traffic trunk as aggregate traffic from point A to
> > point
> > B.
> >
> >
> > For example from Pop A of a service provider network to Pop B you would
> > always
> > have a "known" load of traffic.  This would be your traffic trunk.
> >
> > -ajay
> > >
> > > Thanks in advance.
> > >
> > > Zhu Heqing, Graduate Student
> > > University of Electronic Science and Technology of China.
> > >
> >
> > --
> > Ajay Simha
> > MPLS Deployment Engineer
> > IOS Technology Division
> > (919) 392-3141
> >
> > "Study as if you were to live forever
> >  Live as if you were to die tomorrow"
> >
> >  - Mahatma Gandhi
> >
> >
>
>

-- 
Ajay Simha
MPLS Deployment Engineer
IOS Technology Division
(919) 392-3141

"Study as if you were to live forever
 Live as if you were to die tomorrow"

 - Mahatma Gandhi