The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Apr> msg00082



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

FW: I-D ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.txt

  • From: "Abes, Andi" <aabes@quarrytech.com>
  • Date: Thu, 13 Apr 2000 13:24:37 -0400


David,


The following are quoted from rsvp-tunnel-05, sections 3.1 and 3.2
It's the description of the Path and RESV messages -
the parts that apply to sender specification.
Both messages contain a session object as well (qouted from 4.6.1)

(4.6.1)
LSP_TUNNEL_IPv4 Session Object

      Class = SESSION, LSP_TUNNEL_IPv4 C-Type = 7

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 tunnel end point address               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MUST be zero                 |      Tunnel ID                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Extended Tunnel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


(4.6.2.1. LSP_TUNNEL_IPv4 Sender Template Object)

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 tunnel sender address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MUST be zero                 |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(3.1 - path message)
      <sender descriptor> ::=  <SENDER_TEMPLATE> <SENDER_TSPEC>
                               [ <ADSPEC> ]
                               [ <RECORD_ROUTE> ]
(3.2 - resv message)

      <FF flow descriptor list> ::= <FF flow descriptor>
                               | <FF flow descriptor list> <FF flow
descriptor>

      <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
                               [ <RECORD_ROUTE> ]

      <SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>

      <SE filter spec list> ::= <SE filter spec>
                               | <SE filter spec list> <SE filter spec>

      <SE filter spec> ::=     <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]


So what does this mean:

In a path message, an LSP is identified by:
  a. the session it belongs to - 
	IPv4 egress address + tunnel ID + extendend TunnelID.
  b. A sender template - 
	the ingress address + LSP ID (unique for the sender).

In a reserve message an LSP is identified by:
  a. The session - same as path.
  b. the filter spec, which is exactly the same as the sender_template


So back to the original questions and issues:

1. For LSP's to be belong to the same session they need 
   to share the same egress point and tunnel ID. 
   If the exteneded tunnel ID is set to the Ingress IP address, only
   LSP's originating at the same ingress could ever belong to the
   same session.

2. For multiple LSP's to share resources, they need to:
   a. belong to the same session (see above)
   b. The egress router needs to assign SE style to the session.



Do you agree with the statements above ?
In light of these statements, do you still believe there 
is a bug in the rsvp-tunnel draft ?


Andi.




> -----Original Message-----
> From: David Charlap [mailto:dcharlap@fore.com]
> Sent: Tuesday, April 11, 2000 7:47 PM
> To: mpls@UU.NET
> Subject: Re: FW: I-D
> ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.txt
> 
> 
> "Abes, Andi" wrote:
> > 
> > The "deviation" in RSVP-TE is that there could be many 
> senders in one
> > host, such that it is not enough to denote the ingress IP 
> address, but
> > the LSP ID is also needed. Each "Sender" is assigned a label, a
> > "flow_spec" and optionaly an Explicit Route.
> 
> You're confusing a few things here, I think.
> 
> Each sender (actually, each PHOP node along the path from each sender)
> is assigned a label by its NHOP node during Resv processing.
> 
> FLOWSPEC objects contain the Qos parameters (could be "best effort" if
> the CoS CType is used) and are also signalled from NHOP to PHOP during
> Resv processing.
> 
> Explicit route objects are signalled from PHOP to NHOP during Path
> processing.  They are not assigned to senders, but are generated by
> senders.  (Or ingress routers in the MPLS world.)
> 
> -- David
>