The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Mandatory objects when using RSVP-TE for LSP Tunnels
Jean-Bertos Simo wrote: > > In draft-ietf-mpls-rsvp-lsp-tunnels-08.txt Please note that the current draft is version -09. > , <sender descriptor> and <LABEL_REQUEST> are mandatory objects in > a Path Message. I would like someone to enlighten me about the > following issues: > > 1) What's the expected behavior of an RSVP-capable router that > receives a Path Message: > - without a <LABEL_REQUEST> object? This menans that the Path message may not be used for LSP setup. If your router is capable of using RSVP to signal resource reservations on unlabeled packets (aka classical RSVP, as defined by RFC 2205), then you can process the Path message. If your router only uses RSVP for setting up LSPs, then a required object is missing - drop the packet. > - without a <sender descriptor> object? If your RSVP implementation is only capable of setting up LSPs, then mandatory objects are missing - drop the packet. If your RSVP implementation is capable of classical RSVP operation, then it should accept the packet. A missing sender descriptor is legal if a WF-style reservation is reserved by the egress router, since WF style does not require identification of the sender. Note that WF style reservation is not valid for MPLS. > My understanding is that the Path Message can be silently dropped or > the router can return a PathErr Message. However, my preference would > go to dropping the Path Message to reduce traffic load. There is no error code defined that you could use in a PathErr for this. Therefore, you should not generate a PathErr in this situation. > 2) Are these two objects mandatory in a PathTear Message when dealing > with a LSP_TUNNEL_IPV4_SESSION session object? LABEL_REQUEST is not required for PathTear. It is not part of the BNF of RFC-2205 (obviously), and no updated BNF is provided in the RSVP-TE draft. Sender decriptors are optional in PathTear, in the same sense as they are optional in Path messages. I'm not 100% certain, but it's my understanding that a sender descriptor is needed when tearing down any Path that was set up using a sender dscriptor - since it is required to identify the sender. > 3) If any of these objects is missing in a PathTear Message, what > behavior is expected from a RSVP-capable router? Errors in PathTear messages never result in generation of error-message packets. There is no such thing as a PathTearErr message. If a required object is missing, the packet is dropped. > 4) When processing a PathTear Message, do we have to check whether > the <SENDER_TEMPLATE> or <SENDER_TSPEC> objects are empty or > containing any data? Read RFC 2205. Section 3.1.5. TSPEC and ADSPEC are optional and should be ignored in PathTear messages. SENDER_TEMPLATE is required to identify the sender. If it is missing, then you can't identify which sender in the session is being torn. > 5) Can anyone provide me references where I can find mandatory > objects of Teardown, Error and Confirmation messages of RSVP-TE? RFC 2205. -- David
|
|