Internet DRAFT - draft-or-psc-cap-mode

draft-or-psc-cap-mode







Network Working Group                                         E. Osborne
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Experimental                                   JD. Ryoo
Expires: April 24, 2014                                             ETRI
                                                         H. van Helvoort
                                                     Huawei Technologies
                                                         A. D'Alessandro
                                                          Telecom Italia
                                                               T. Cheung
                                                                    ETRI
                                                        October 21, 2013


                     Capabilities and Modes in PSC
                        draft-or-psc-cap-mode-01

Abstract

   This document introduces capabilites and modes to PSC.  A capability
   is an individual behavior, and a node's set of capabilities are
   signalled using the method given in this draft.  A mode is a
   particular combination of capabilities.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 24, 2014.

Copyright Notice




Osborne, et al.          Expires April 24, 2014                 [Page 1]

Internet-Draft                psc-cap-mode                  October 2013


   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Capabilities  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Sending the Capabilities TLV  . . . . . . . . . . . . . .   3
       2.1.1.  What to send  . . . . . . . . . . . . . . . . . . . .   3
       2.1.2.  When  to send it  . . . . . . . . . . . . . . . . . .   4
     2.2.  Receiving the Capabilities TLV  . . . . . . . . . . . . .   4
       2.2.1.  Comparing Capabilties TLVs  . . . . . . . . . . . . .   4
       2.2.2.  Handling a missing TLV  . . . . . . . . . . . . . . .   4
     2.3.  Handling errors . . . . . . . . . . . . . . . . . . . . .   4
       2.3.1.  TLV Timeout . . . . . . . . . . . . . . . . . . . . .   4
       2.3.2.  TLV Mismatch  . . . . . . . . . . . . . . . . . . . .   5
       2.3.3.  Handling an error . . . . . . . . . . . . . . . . . .   5
   3.  Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  PSC Mode  . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  APS Mode  . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.2.1.  SF-P and FS priority swap . . . . . . . . . . . . . .   6
       3.2.2.  Modified non-revertive behavior and MS-W  . . . . . .   6
       3.2.3.  Signal degrade  . . . . . . . . . . . . . . . . . . .   6
       3.2.4.  Exercise  . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Backward compatability  . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   This document brings two things to PSC - Capabilies, and Modes.  A
   Capability is an individual behavior whose use is signalled in a
   Capabilities TLV inside PSC, and a Mode is a predefined set of
   Capabilities.




Osborne, et al.          Expires April 24, 2014                 [Page 2]

Internet-Draft                psc-cap-mode                  October 2013


2.  Capabilities

   A Capability is an individual behavior whose use is signalled in a
   Capabilities TLV inside PSC.  The format of the Capabilities TLV is:

           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
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |  Type=Capabilities            |    Length                     |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                        Options Value                          |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




   The Length is the length of the Options Value, and is in octets.  The
   value for the Type field is TBD pending IANA allocation.

2.1.  Sending the Capabilities TLV

   There are two things to consider when sending a capabilities TLV -
   what to send, and when to send it.

2.1.1.  What to send

   The Value of the Capabilities TLV can be any length, as long as it is
   a multiple of 4 octets.  An implementation MUST send only as long a
   Value as it needs to.  Other parts of this document discuss five
   capabilities that are signalled using the 5 least significant bits;
   if a node wishes to signal these five, it MUST send an Options Value
   of 4 octets.  A node would only send an Options Value of >4 octets if
   it had more than 32 Capabilities to indicate.  All unused bits MUST
   be set to zero.

   If the bit defined for an individual capabilitiy is set to 1, that
   indicates the sending node's intent to use that capability in the
   protection domain.  If a bit is set to 0, the sending node does not
   intend to use the indicated capability in the protection domain.
   Note that it is not possible to distinguish between the intent not to
   use a capability and a node's complete non-support (i.e. lack of
   implemntation) of a given capabilty.









Osborne, et al.          Expires April 24, 2014                 [Page 3]

Internet-Draft                psc-cap-mode                  October 2013


2.1.2.  When to send it

   PSC sends messages for two reasons - messages in response to external
   inputs, and periodic retransmission of current status.  It is not
   necessary to send the Capabilties TLV with every PSC packet.  Indeed,
   it may be expensive to send and to parse an Capabilities TLV attached
   to a packet intended to trigger a protection switch or other real-
   time behavior.  However, it is also true that if a node does not
   periodically send its Capabilities TLV, the receiving node cannot
   tell the difference between a deliberate omission of the Capabilities
   TLV for performance reasons versus an accidental omission due to an
   implementation issue.  To guard against this, a node MUST send its
   Capabilities TLV in every periodic retransmission of current status,
   and MAY send its Capabilities TLV more frequently than that.

2.2.  Receiving the Capabilities TLV

   A node MUST establish a receive timer for the Capabilities TLV.  By
   default this MUST be three times the periodic retransmission timer of
   five seconds - so, fifteen seconds.  Both the periodic retranmission
   time and the timout SHOULD be configurable by the operator.  When a
   node receives a Capabilties TLV it resets the timer to fifteen
   seconds.  If the timer expires, the node behaves as in Section 2.3.

2.2.1.  Comparing Capabilties TLVs

   When a node receives a Capabilites TLV it MUST compare it to its most
   recent transmitted Capabilites TLV.  If the two are equal, the
   protection domain is said to be running in the mode indicated by that
   set of capabilites (see Section 3).

2.2.2.  Handling a missing TLV

   As mentioned in section 2.1.2, a node may not send the Capabilties
   TLV with every PSC message.  However, a node MUST send the
   Capabilities TLV as part of its periodic state retransmission.

2.3.  Handling errors

   This section covers the two possible errors - a TLV timeout and a TLV
   mismatch - and the error handling procedures in both cases.

2.3.1.  TLV Timeout

   If the Capabilities TLV receive timer expires, a node is said to have
   timed out.  Whe this happens, the node MUST alert the operator and
   MUST behave as in Section 2.3.4, "Handling an error".




Osborne, et al.          Expires April 24, 2014                 [Page 4]

Internet-Draft                psc-cap-mode                  October 2013


2.3.2.  TLV Mismatch

   If the sent and received Capabilties TLVs are not equal, this
   indicates a capabilities mismatch.  For timer and timeout purposes, a
   capabilities mismatch is treated as a missed TLV.  That is, the
   received TLV is not taken as an input to the receive timer for
   Capabilties TLV refresh purposes.  A node MAY retain the received TLV
   for logging, alert or debug purposes.

2.3.3.  Handling an error

   If a node decides that it is in an error state in respect to the
   Capabilities TLV, it MUST do two things:

   1) Indicate the detected mismatch to the operator by the usual alert
   mechanisms (e.g. syslog).

   2) Not make any state transitions based on the contents of any PSC
   messages

   To expand on point 2 - assume node A is receiving NR(0,0) from its
   PSC peer Z and is also receiving a mismatched set of capabilities
   (e.g. received 0x4, transmitted 0x5).  If Z detects a local SF-W and
   wants to initiate a protection switch (that is, by sending SF(1,1)),
   Node A MUST NOT react to this input by changing its state.  A node
   MAY increase the severity or urgency of its alarms to the operator,
   but until the operator resolves the mismatch in the Capabilites TLV
   the protection domain will likely operate in an inconsistent state.

3.  Modes

   A Mode is a given set of Capabilities.  Modes are shorthand;
   referring to a set of capabilites by their individual values or by
   the name of their mode does not change the protocol behavior.  This
   document defines two modes - PSC and APS.

   << are those the right names?  TBD. >>

   << how to define future modes.  TBD. >>

3.1.  PSC Mode

   PSC Mode is defined as the lack of any Capabilities - that is, a
   Capabilities set of 0x0.  It is the behavior specified in RFC6378.
   There are two ways to declare PSC Mode.  A node can send a
   Capabilities TLV of 0x0, or it can send no Capabilities TLV at all.
   This is further explored in section 4.




Osborne, et al.          Expires April 24, 2014                 [Page 5]

Internet-Draft                psc-cap-mode                  October 2013


3.2.  APS Mode

   APS Mode is defined as the use of five specific capabilties.  These
   capabilites are defined in other documents, but are repeated here in
   order to define the mode.  They are listed below.  APS Mode is
   indicated with a Capabilites TLV of 0x1F.

3.2.1.  SF-P and FS priority swap

   This feature is defined in draft-rhd-mpls-tp-psc-priority and is
   assigned bit 0x1.

3.2.2.  Modified non-revertive behavior and MS-W

   These are both defined in draft-cdh-mpls-tp-psc-non-revertive but are
   negotiated seperately.. Modified NR behavior is assigne bit 0x2 and
   MS-W is assigned bit 0x4.

3.2.3.  Signal degrade

   This feature is defined in draft-rhd-mpls-tp-psc-sd.  It is assigned
   bit 0x8.

3.2.4.  Exercise

   This feature is defined in draft-dj-mpls-tp-exer-psc.  It is assigned
   bit 0x10.

4.  Backward compatability

   As defined in Section 3, PSC Mode is indicated either with a
   Capabilties TLV of 0x0 or the lack of any Capabilities TLV.  This is
   to allow backward compatability between two nodes - one which can
   send the Capabilities TLV, and one which cannot.

   RFC6378 does not define how to handle an unrecognized TLV.  There may
   be some implementations that silently discard an unrecognized TLV,
   and some that take more drastic steps like refusing to allow PSC to
   operate.  Thus, a node which has the ability to send and receive the
   PSC Mode Capabilities TLV MUST be able to both send the PSC Mode
   Capabilties TLV and send no Capabilities TLV at all.  An
   implementation MUST be configurable between these two choices.

   One question that arises from this dual definition of PSC Mode is,
   what happens if a node which was sending a non-null Capabilities TLV
   (e.g. APS Mode) sends PSC packets without any Capabilites TLV?  This
   case is handled as follows:




Osborne, et al.          Expires April 24, 2014                 [Page 6]

Internet-Draft                psc-cap-mode                  October 2013


   If a node has never, during the life of a PSC session, received a
   Capabilites TLV from a neighbor, the lack of a Capabilites TLV is
   treated as receipt of a PSC Capabilites TLV.  This allows for interop
   between nodes which support the PSC Mode TLV and nodes which do not,
   and are thus implicitly operating in PSC Mode.

   If a node has received a non-null Capabilites TLV (e.g. APS Mode)
   during the life of a PSC session and then receives a PSC packet with
   no Capabilites TLV, the receiving node MUST treat the lack of
   Capabilites TLV as simply a lack of refresh.  That is, the receipt of
   a PSC packet with no Capabilites TLV simply does not reset the
   receive timer defined in Section 2.2

5.  IANA Considerations

   - A value for the Cap TLV

   - A registry for the capabilities inside the Cap TLV

6.  Security Considerations

   None.

7.  Acknowledgements

8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Authors' Addresses

   Eric Osborne
   Cisco Systems, Inc.

   Email: eosborne@cisco.com


   Jeong-Dong Ryoo
   ETRI


   Huub van Helvoort
   Huawei Technologies

   Email: Huub.van.Helvoort@huawei.com





Osborne, et al.          Expires April 24, 2014                 [Page 7]

Internet-Draft                psc-cap-mode                  October 2013


   Alessandro D'Alessandro
   Telecom Italia

   Email: alessandro.dalessandro@telecomitalia.it


   Taesik Cheung
   ETRI

   Email: cts@etri.re.kr









































Osborne, et al.          Expires April 24, 2014                 [Page 8]