The MPLS WG Archive

[Anil Yelundur <ayelund@yahoo.com>]

Mort,
See responses inline,

--- "Pour, Mort" <mpour@celoxnetworks.com> wrote:
> 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?
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.

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

> 
> -----Original Message-----
> From: Ajay Simha [mailto:asimha@cisco.com]
> Sent: Saturday, September 15, 2001 11:40 AM
> To: Pour, Mort
> Cc: Hemant P. Kelkar; zhuheqing@huawei.com;
> mpls-ops@mplsrc.com;
> mpls@UU.NET
> 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: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)
> 
=== message truncated ===


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