Subject: LinkSummary in draft-lang-mpls-lmp-01.txt missing fields?

From: "Dawkins, Spencer" <[email-masked]>
Date: Thu, 17 Aug 2000 14:25:35 -0500

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

---

From: Jonathan Lang <[email-masked]>
Date: Mon, 21 Aug 2000 14:07:39 -0700

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:[email-masked]]
> Sent: Thursday, August 17, 2000 12:26 PM
> To: 'IETF MPLS mailing list'
> Subject: LinkSummary in draft-lang-mpls-lmp-01.txt missing fields?
> 
>

---

From: "Dawkins, Spencer" <[email-masked]>
Date: Tue, 22 Aug 2000 08:33:22 -0500

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

> From:	Jonathan Lang [SMTP:[email-masked]]
> 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,

---

From: Jonathan Lang <[email-masked]>
Date: Tue, 22 Aug 2000 08:42:54 -0700

Spencer,
  See comments inline.

-Jonathan

> Sent: Tuesday, August 22, 2000 6:33 AM
> Subject: RE: LinkSummary in draft-lang-mpls-lmp-01.txt missing fields?
> 
> 
yes

> LinkSummary, pointing to the active control channel as the protected
yes

> 
> o so switching to a backup control channel looks (roughly) 
> like switching to any other protection channel.
The actual switching to a backup control channel looks quite different from
switching to a protection channel because of the procedure that is used in
LMP for the switchover.  For the component links, the switchover to a
protection channel is handled by the signaling protocol (e.g., RSVP or LDP).
Having said this, the mechanism to map the protection channels to working
channels is the same for control channel and component links.
 
> 
> 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.
> 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.
The signaling of data channel switchover is not done in LMP, but is
relegated to the signaling protocol that is being used.  LMP is used to
exchange the working/protect channel mappings and to assist in the fault
isolation.  Therefore, using your above example, (1) would be the proper
operation.

> I also noticed that there isn't a section 8...
yes, I had some numbering problems...