The MPLS WG Archive

["Hong Liao" <hliao@telcordia.com>]

You are right, that is what I observed from the router.

Actually I sent out the path msg with correct checksum and wrong ctype, but
I did not get the PathErr msg back, I think the Vender did not implement it
properly.

Thanks,

Julia



>>Be sure, however, that the rest of the packet actually is correct.  If
you took the binary data from a valid Path message and just changed the
C-Type field and nothing else, then the RSVP checksum will be invalid.
An invalid checksum will cause the router to drop the message without
generating any errors.


then how can I let router generate this patherr for the following scenario?

> An RSVP router that recognizes the LABEL_REQUEST object but
>    does not recognize the C_Type sends a PathErr with the error code
>    "Unknown object C_Type" toward the sender.
>
> so I have path msg sent out with correct LRO class, and length, but
> it has unknown ctype, such as '0F'H,
> but receiver will not send out patherr from it.



Thanks,

Julia



                                                                                                         
                    David Charlap                                                                        
                    <david.charlap@ma        To:     mpls@UU.NET                                         
                    rconi.com>               cc:     (bcc: Hong Liao/Telcordia)                          
                                             Subject:     Re:                                            
                    08/22/01 12:44 PM                                                                    
                                                                                                         
                                                                                                         





Hong Liao wrote:
>
> []  But even that is the case,  --bad checksum, the Router should
> send back the path error msg with error code 23.
>
> ----------   spec 2205.
>  Error Code = 23: RSVP System error
>
> o    Wrong-length message: RSVP Length field does not match message
>         length.
>
>    o    Unknown or unsupported RSVP version.
>
>    o    Bad RSVP checksum
>
>    o    INTEGRITY failure

You deleted four paragraphs of text between the line "Error Code = 23"
and the list of conditions.  Among other things, those four paragraphs
contain:

     ... Should a programming error allow an RSVP to create a
     malformed message, the error is not generally reported to
     end systems in an ERROR_SPEC object; instead, the error is
     simply logged locally, and perhaps reported through network
     management mechanisms.

     The only message formatting errors that are reported to end
     systems are those that may reflect version mismatches, and
     which the end system might be able to circumvent, e.g., by
     falling back to a previous CType for an object; see code 13
     and 14 above.

     The choice of message formatting errors that an RSVP may
     detect and log locally is implementation-specific, but it
     will typically include the following:

     ...  (list of conditions)

The RFC explicitly states that conditions like wrong-length message,
unknown RSVP version, bad checksum and INTEGRITY failure do _NOT_ cause
the generation of error messages.  The packets are dropped.  The error
condition may be logged or reported through network management.

-- David