Subject: RE: Re: Traffic Trunk?

From: Srinivas Nukala <[email-masked]>
Date: Sat, 15 Sep 2001 15:18:14 -0700

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:
> > > >
> > > > 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
>

---

From: [email-masked]
Date: Sat, 15 Sep 2001 19:40:56 -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?

> > trunks can have different attributes, then how can the LSP 
> accomodate> them all. If the trunks must have the same attribute, 
> then there is
> > > in voice we have a voice trunk everytime I call you over the 
> phone).> >
> > > " A note on terminology: The concept of MPLS traffic trunks is 
> used> > 	   extensively in the remainder of this document. 
> > According to Li
> > > and
> > >    traverses. In practice, the terms LSP and traffic trunk are 
> often> >    used synonymously. Additional characteristics of 
> traffic 
> > trunks as
> > > > > Can you give me a specific example or more specific 
> description?> > >
> > > > have a "known" load of traffic.  This would be your traffic 
> trunk.> > >
> > > > -ajay
> > > > >
> > > > > Thanks in advance.
> > > > >

---

From: "Pour, Mort" <[email-masked]>
Date: Sun, 16 Sep 2001 10:26:25 -0500

Anil,
1- Can we have several trunks each with a distinct set of attributes on the
same LSP 
which yet may have a different set of attributes?
How do we even signal the attributes of a trunk? For example in E-LSP the 
bandwidt is set for the LSP itself and not for the PHBs (if we do not
implement
draft <draft-ganti-mpls-diffserv-elsp-00.txt>. Am I right on this?

2- Another question that I have is that RSVP-TE does not seem to support all
the attributes in 
RFC 2702. At least not stated specifically.

Thanks
Mort

-----Original Message-----
From: Anil Yelundur [mailto:[email-masked]]
Sent: Sunday, September 16, 2001 9:59 AM
To: Pour, Mort; 'Ajay Simha'
Cc: Hemant P. Kelkar; [email-masked]; [email-masked];
[email-masked]

Mort,
See responses inline,

> If they are not signaled, then how can they be
In the case of E-LSP, these attributes can be
configured manually or thru a centralized NMS / Policy
Server to all routers in a domain.

> realy only one trunk per LSP. The why the
> distinction between trunks and
> LSPs
In the case of E-LSP, the same LSP can carry different
PHBs (traffic trunks in this case) and the distinction
is done via the EXP bits in the label.

> 3- RFC 2
702 states that they are fundamentally
> distinct from the LSP over
> which they are
A traffic trunk has a specific CoS & is destined to a
specific egress router. An LSP is a transport
mechanism (label switched path) to carry the traffic
trunk. The extra information in the label of the
packet provides information to provide differential
treatment to the specific traffic trunk at every hop
in the path towards the destination.

Regards,
Anil Yelundur

> > I have some questions regariding this as well. All
> the attributes defined
> in
> > 2702 are
> > Are they signaled? It seems to me that LSPs are
> what are signaled. But
> LSPs
> > 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.
> 
> We would specify this "attribute" of the trunk under
> the tunnel.  After it
> is
>    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:
> 
> > > 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
> > 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
> > Many flows would constitue a trunk (in the real
> deployment context.  Of
> > course
> > I think it is more of "Traffic" characteristics we
> are talking about here
> >    Rekhter [3], a traffic trunk is an aggregation
> of traffic flows of
> >    to which specific characteristics can be
> associated. It is useful to
> >    view traffic trunks as objects that can be
> routed; that is, the path
> >    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
> >    specification of the label switched path
> through which the traffic
> >    used synonymously. Additional characteristics
> of traffic trunks as
=== message truncated ===

__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/