Subject: RE: Re: Traffic Trunk?

From: "Pour, Mort" <[email-masked]>
Date: Sat, 15 Sep 2001 14:56:14 -0500

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?
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. 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.
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: Anil Yelundur <[email-masked]>
Date: Sun, 16 Sep 2001 07:58:30 -0700 (PDT)

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.

> distinction between trunks and
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

> > > Date: Sat, 15 Sep 2001 09:01:41 -0400 (Eastern
=== message truncated ===

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