Subject: Traffic Trunk?

From: "Zhu Heqing" <[email-masked]>
Date: Sat, 15 Sep 2001 14:09:49 +0800

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?

Thanks in advance.

Zhu Heqing, Graduate Student
University of Electronic Science and Technology of China.

---

From: [email-masked]
Date: Sat, 15 Sep 2001 19:07:12 -0400

I think Traffic Trunks are a result of aggregation of flows based on 
their traffic classes and placed inside a LSP. Many different trunks, 
each with its own traffic class may or may not share the same LSP if 
they have different traffic classes.
 
 -Rajiv

----- Original Message -----
From: Srinivas Nukala <[email-masked]>
Date: Saturday, September 15, 2001 6:18 pm
Subject: RE: Re: Traffic Trunk?

> Let me see if I understand correctly and can explain it to you.
> 
> Traffic Trunk is a representation of a set of traffic flows with 
> common end points, neednot
> necessarily be classified into the same class of traffic, a set of 
> traffic characteristics
> associated with it (for eg. max rate, max burst size, acceptable 
> latency etc.) and a set of
> policing attributes.
> 
> If it is an MPLS network it is the LSP through which you are 
> achieving it
> (If it is a non-MPLS domain you have a different physical 
> representation for the same trunk)
> When defining a trunk you don't say how you want to physically 
> route the packets belonging to 
> this trunk, it is through the LSP by which you achieve it. 
> So, when you define a Trunk you only know where to go and what you 
> want but not how to reach there
> and how it can be realized.
> 
> > I still have many questions
> > 
> > 1- RFC2702 states that traffic trunks hav policing attributes.
> > If they are not signaled, then how can they be policed?
>  Can't they be administratively configured ??
> 
> > 2- Many documents state that an LSP may carry several trunks. If the
> > trunks can have different attributes, then how can the LSP 
> accomodate> them all. If the trunks must have the same attribute, 
> then there is
> > realy only one trunk per LSP.
>  Not sure
> 
> > The why the distinction between 
> > trunks and
> > LSPs
> 
> > 3- RFC 2702 states that they are fundamentally distinct from 
> > the LSP over
> > which they are
> > carried. But then in the next sentence states that the two are used
> > synonimously.
>  See above.
> 
> > I have a hard time to see the distinction.
> > Any response to c;arify is greatly appreciated.
> > Mort
> > 
> > -----Original Message-----
> > From: Ajay Simha [mailto:[email-masked]]
> > Sent: Saturday, September 15, 2001 11:40 AM
> > To: Pour, Mort
> > Cc: Hemant P. Kelkar; [email-masked]; [email-masked];
> > [email-masked]
> > Subject: RE: Re: Traffic Trunk?
> > 
> > 
> > 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:[email-masked]]
> > > Sent: Saturday, September 15, 2001 9:34 AM
> > > To: Hemant P. Kelkar
> > > Cc: [email-masked]; [email-masked]; [email-masked]
> > > 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 <[email-masked]>
> > > > To: Zhu Heqing <[email-masked]>
> > > > Cc: [email-masked]
> > > > Subject: Re: Traffic Trunk?
> > > >
> > > > On Sat, 15 Sep 2001, Zhu Heqing wrote:
> > > >
> > > > > Hi, All:
> > > > >
> > > > > 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.
> > > > >
> > > > --
> > > > 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
> > 
>