The MPLS WG Archive

["Dawkins, Spencer" <Spencer.DAWKINS@fnc.fujitsu.com>]

Thanks, this helps a lot. If I understand this correctly, 

o the active control channel is listed as a working channel in the
LinkSummary, 

o any backup control channels are listed as protection channels in the
LinkSummary, pointing to the active control channel as the protected
channel,

o so switching to a backup control channel looks (roughly) like switching to
any other protection channel.

I think I understand how control channel switchover happens (section 4.1.3
is pretty clear), but am a little less clear on how data channel switchover
happens. Most of Section 7 deals with fault detection and isolation, not
with signaling that data channel switchover is occurring/has occurred.
Actually, this is a good place to start.

When a data channel fails and the upstream node (right?) sends an updated
LinkSummary (including the former protection channel listed as a working
channel), does this mean (1) the switchover has already occurred, or (2) the
switchover should occur? I'm guessing (2) from the end of section 7.2, but
I'm not sure I saw this explicitly stated.

I also noticed that there isn't a section 8...

Spencer

> -----Original Message-----
> From:	Jonathan Lang [SMTP:jplang@calient.net]
> Sent:	Monday, August 21, 2000 4:08 PM
> To:	'Dawkins, Spencer'; 'IETF MPLS mailing list'
> Subject:	RE: LinkSummary in draft-lang-mpls-lmp-01.txt missing
> fields?
> 
> Spencer,
>   Backup CCIds are listed in the Protection channel subobjects of the
> LinkSummary message.  Recall from the text in Section 8.5.1 that the "list
> of working channels MUST include the control channel".  The identification
> of backup control channels is mentioned in the Protection Channel
> subobject
> format.  To make things clear, I can add to the LinkSummary text  as
> follows
> (new text in <<>>):
> 
>    "The LinkSummary message contains a list of working channel 
>    subobjects and protection channel subobjects.  The list of working 
>    channels MUST include the control channel.  <<Any backup control
> channels
> that
>    are defined MUST be included in the list of protection channel
> subobjects.  Note that
>    a backup control channel can also be a working component link (provided
> it has
>    preemptive priority over the working component link), so it is possible
> to appear
>    in both the working channel subobject as well as the protection channel
> subobject.>>"
> 
> 
> -Jonathan
> 
> > -----Original Message-----
> > From: Dawkins, Spencer [mailto:Spencer.DAWKINS@fnc.fujitsu.com]
> > Sent: Thursday, August 17, 2000 12:26 PM
> > To: 'IETF MPLS mailing list'
> > Subject: LinkSummary in draft-lang-mpls-lmp-01.txt missing fields?
> > 
> > 
> > The text in Section 6.0 of this draft says
> > 
> >    "The LinkSummary message contains the primary 
> >    and backup CCIds, the IP address for the link (binding the 
> > CCIds to 
> >    the link IP addresses), and the local and remote LinkIds for each 
> >    component link and their associated priorities."
> > 
> > but I don't see the backup CCIds in the LinkSummary message 
> > described in
> > 8.5.1:
> > 
> >  The format of the LinkSummary 
> >    message is as follows: 
> >     
> >    <LinkSummary Message> ::= <Common Header> <LinkSummary> 
> >     
> >    The LinkSummary Object has the following format: 
> >     
> >     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 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >    |                          MessageId                            | 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >    |                     Interface IP Address                      | 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >    |                          NumWorking                           | 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >    |                        NumProtection                          | 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >    |                                                               | 
> >    //                 (working channel subobjects)                // 
> >    |                                                               | 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >    |                                                               | 
> >    //               (protection channel subobjects)               // 
> >    |                                                               | 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > 
> > and the Common Header looks like
> > 
> >    In addition to the standard IP header, all LMP control-channel 
> >    messages have the following common header: 
> >     
> >     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 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >    | Vers  |    Flags      |    Msg Type   |   (Reserved)          | 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> >    |                      Control Channel Id                       | 
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> > 
> > Am I missing something obvious?
> > 
> > Spencer
> >