tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6240

Proposed STD
Pages: 67
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: PWE3

Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) MIB Using SMIv2

Part 1 of 3, p. 1 to 8
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                     D. Zelig, Ed.
Request for Comments: 6240                                    PMC-Sierra
Category: Standards Track                                  R. Cohen, Ed.
ISSN: 2070-1721                                        Resolute Networks
                                                          T. Nadeau, Ed.
                                                         CA Technologies
                                                                May 2011


 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH)
          Circuit Emulation over Packet (CEP) MIB Using SMIv2

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects for modeling Synchronous
   Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits
   over a Packet Switch Network (PSN).

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6240.

Copyright Notice

   Copyright (c) 2011 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.

Page 2 
   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1. Introduction ....................................................3
   2. Conventions Used in This Document ...............................3
   3. Terminology .....................................................3
   4. The Internet-Standard Management Framework ......................4
   5. Feature Checklist ...............................................4
   6. MIB Module Description and Usage ................................5
      6.1. PW-CEP-STD-MIB Summary .....................................5
      6.2. MIB Modules Required for IMPORTS ...........................5
      6.3. PW-STD-MIB Module Usage ....................................6
      6.4. PW-CEP-STD-MIB Module Usage ................................6
      6.5. Example of PW-CEP-STD-MIB Usage ............................7
   7. Object Definitions ..............................................8
   8. Security Considerations ........................................64
   9. IANA Considerations ............................................65
   10. References ....................................................65
      10.1. Normative References .....................................65
      10.2. Informative References ...................................66
   11. Contributors ..................................................67

Top      ToC       Page 3 
1.  Introduction

   This document describes a model for managing encapsulated SONET/SDH
   Time Division Multiplexed (TDM) digital signals for transmission over
   a Packet Switched Network (PSN).

   This document is closely related to [RFC4842], which describes the
   technology to encapsulate TDM signals and provides the Circuit
   Emulation Service over a Packet Switched Network (PSN).

   The model for Circuit Emulation over Packet (CEP) management is a MIB
   module.  The PW-CEP-STD-MIB module described in this document works
   closely with the MIB modules described in [RFC5601] and the textual
   conventions defined in [RFC5542].  In the spirit of [RFC2863], a CEP
   connection will be a pseudowire (PW) and will therefore not be
   represented in the ifTable.

   CEP is currently specified to carry "structured" SONET/SDH paths,
   meaning that each SONET/SDH path or Virtual Tributary (VT) within the
   section/line/path can be processed separately.  The SONET/SDH
   section/line/path interface stack is modeled within [RFC3592].

   This document adopts the definitions, acronyms, and mechanisms
   described in [RFC3985].  Unless otherwise stated, the mechanisms of
   [RFC3985] apply and will not be redescribed here.

2.  Conventions Used in This Document

   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 [RFC2119].

3.  Terminology

   CEP terminology comes from [RFC4842], which describes a mechanism for
   transporting SONET/SDH Time Division Multiplexed (TDM) digital
   signals over a packet-oriented network.  The mechanism for structured
   emulation (as outlined in [RFC4842]) terminates the SONET/SDH section
   and line overhead and then breaks the SONET/SDH path's Synchronous
   Payload Envelope (SPE) into fragments for transmission over a PSN.
   Mechanisms for terminating the SONET/SDH path overhead and extracting
   SONET VTs are also described in [RFC4842].  Mechanisms for fractional
   SONET/SDH SPE emulation are described in [RFC4842].  A CEP header
   that contains a sequence number and pointer adjustment information is
   appended at the beginning of each fragment to provide information
   regarding where the SPE begins within the packet stream (see
   [RFC4842]).

Top      ToC       Page 4 
   "Outbound" references the traffic direction in which a SONET/SDH
   path's payload (SPE) is received, adapted to packet, assigned a PW
   label, and sent into the PSN.

   Conversely, "inbound" is the direction in which packets are received
   from the PSN and packet payloads are reassembled back into an SPE and
   inserted as a SONET/SDH path into the SONET/SDH section and line.

   Since a SONET/SDH path is bidirectional and symmetrical, CEP uses the
   same SONET/SDH timeslot, SONET/SDH width, and packet size.  Inbound
   and outbound PW labels may differ.

4.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

5.  Feature Checklist

   The PW-CEP-STD-MIB module is designed to satisfy the following
   requirements and constraints:

   -  The MIB module is designed to work with the PW-STD-MIB [RFC5601]
      module.

   -  The MIB module is independent of the PSN type.

   -  The MIB module supports all the signal types as defined in
      [RFC4842]: SPE, fractional SPE, VT, both SONET and SDH mapping.
      The MIB module also supports all the optional features as defined
      in [RFC4842].

   -  The MIB module reports all the statistics as defined by [RFC4842].

Top      ToC       Page 5 
6.  MIB Module Description and Usage

   For clarity of the description below, in most cases, we refer to the
   SONET path signal configuration only, but the same examples are
   applicable for SDH signals and VT-level processing as well, as
   described in [RFC3985].

6.1.  PW-CEP-STD-MIB Summary

   -  The CEP PW Table (pwCepTable) contains the SONET/SDH path/VT
      ifIndex, SONET/SDH path timeslot, the pwCepCfgTable index, config
      error indications, and various status indications.

   -  The CEP PW Configuration Parameter Table (pwCepCfgTable) has
      objects for CEP PW configuration.  In situations where sets of
      config objects are common amongst more than one CEP PW, a single
      entry here may be referenced by many pwCepTable entries.

   -  The CEP PW Performance Current Interval Table
      (pwCepPerfCurrentTable) contains CEP stats for the current
      15-minute period.

   -  The CEP Performance 15-Minute Interval Table
      (pwCepPerfIntervalTable) is similar to the pwCepPerfCurrentTable.
      It contains historical intervals (usually 96 15-minute entries to
      cover a 24-hour period).

      Note: the performance interval statistics are supported by CEP due
      to the very function of CEP, that is, processing SONET/SDH.  See
      [RFC3592].

   -  The CEP Performance 1-Day Table (pwCepPerf1DayIntervalTable)
      contains statistics accumulated during the current day and
      contains previous days' historical statistics.

   -  The CEP Fractional Table (pwCepFracTable) adds configuration and
      monitoring parameters for fractional SPE PWs.

6.2.  MIB Modules Required for IMPORTS

   The PW-CEP-STD-MIB IMPORTS objects from SNMPv2-SMI [RFC2578],
   SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], SNMP-FRAMEWORK-MIB
   [RFC3411], PerfHist-TC-MIB [RFC3593], HC-PerfHist-TC-MIB [RFC3705],
   IF-MIB [RFC2863], PW-STD-MIB [RFC5601], and PW-TC-STD-MIB [RFC5542].

Top      ToC       Page 6 
6.3.  PW-STD-MIB Module Usage

   The MIB module structure for defining a PW service is composed of
   three layers of MIB modules functioning together.  This general model
   is defined in the Pseudowire Emulation Edge-to-Edge (PWE3)
   architecture [RFC3985].  The layering model is intended to
   sufficiently isolate PW services from the underlying PSN layer that
   carries the emulated service.  This is done at the same time as
   providing a standard means for connecting any supported services to
   any supported PSNs.

   The first layer, known as the service layer, contains service-
   specific modules such as the one defined in this document.  These
   modules define service-specific management objects that interface or
   collaborate with existing MIB modules for the native version of the
   service.  The service-specific module "glues" the standard modules to
   the PWE3 MIB modules.  The PW-CEP-STD-MIB module defined in this memo
   serves as one of the PW-type-specific MIB modules.

   The next layer of the PWE3 MIB framework is the PW-STD-MIB module
   [RFC5601].  This module is used to configure general parameters of
   PWs that are common to all types of emulated services and PSNs.  This
   layer is connected to the service-specific layer above and the PSN
   layer below.

   The PSN layer provides PSN-specific modules for each type of PSN.
   These modules associate the PW with one or more "tunnels" that carry
   the service over the PSN.  These modules are defined in other
   documents.  This module is used to "glue" the PW service to the
   underlying PSN-specific MIB modules.

6.4.  PW-CEP-STD-MIB Module Usage

   Configuring a CEP PW involves the following steps.

   (1)  First, create an entry in the pwTable:

        -  Follow steps as defined in [RFC5601].

   (2)  Configure the PSN tunnel in the respective PSN-specific PWE3 PSN
        glue MIB modules and the respective PSN-specific MIB modules.
        Configure the SONET path parameters:

        -  Set the SONET path width in the sonetPathCurrentTable
           [RFC3592].

        -  Set the SONET path index and the SONET path starting timeslot
           in the pwCepTable.

Top      ToC       Page 7 
        NOTE: The agent creates an entry in the pwCepTable based on the
        entry created in the pwTable.

   (3)  Configure the CEP PW:

        -  If necessary, create an entry in the pwCepCfgTable (a
           suitable entry may already exist).  Set packet length, etc.

        -  Set the index of this pwCepCfgTable entry in the pwCepTable.

   (4)  Observe the CEP PW:

        -  Once a CEP PW is operational, the pwCepPerfCurrentTable,
           pwCepPerfIntervalTable, and pwCepPerf1DayIntervalTable can be
           used to monitor the various counts, indicators, and
           conditions of the PW.

6.5.  Example of PW-CEP-STD-MIB Usage

   In this section, we provide an example of using the MIB objects
   described in Section 7 to set up a CEP PW.  While this example is not
   meant to illustrate every permutation of the MIB, it is intended as
   an aid to understanding some of the key concepts.  It is meant to be
   read after going through the MIB itself.  See [RFC5601] for an
   example of setting up PSN tunnels.

   First, configure the SONET path width, starting timeslot, and
   associated CEP PW.  In this case, an Synchronous Transport Signal 3c
   (STS-3c) starts at SONET timeslot 1 (and is distributed normally
   within the SONET frame).  In the following example, the ifIndex for
   the sonetPathCurrentEntry is 23, while the pwCepCfgTable index is 9.

   In [RFC3592], sonetPathCurrentEntry (ifIndex = 23):

   {
      sonetPathCurrentWidth           = 3,
      sonetPathCurrentStatus
      ...
      ...
   }

   Create an entry in the pwCepCfgTable (index = 9):

   {
      pwCepCfgSonetPaylaodLength    = 783 -- payload bytes
      pwCepCfgMinPktLength          = 0   -- no minimum
      pwCepCfgPktReorder            = true
      pwCepCfgEnableDBA             = unequipped

Top      ToC       Page 8 
      pwCepCfgRtpHdrSuppress        = false
      pwCepCfgJtrBfrDepth           = 500 -- micro-seconds

      pwCepCfgConsecPktsInsync      = 2   -- Exit Loss of Packet
                                          -- Synchronization (LOPS)
                                          -- state
      pwCepCfgConsecMissingOutSync  = 10  -- Enter LOPS state

      pwCepCfgPktErrorPlayOutValue  = 0xFF -- All ones

      pwCepCfgMissingPktsToSes      =  3  -- packets
      pwCepCfgSesToUas              =  2  -- seconds
      pwCepCfgSecsToExitUas         = 10  -- seconds

      pwCepCfgRowStatus             = createAndGo
   }

   In the PW-STD-MIB module: Get a new index and create a new pwTable
   entry using pwIndexNext (here, the PW index = 83) and pwRowStatus.
   In this new entry, set pwType to 'cep'.  The agent will create a new
   entry in the pwCepTable.  Set the SONET path ifIndex, SONET path
   timeslot, and Cfg Table indexes within this new pwCep table entry:

   {
      pwCepSonetIfIndex     = 23 -- Index of associated entry
                                   -- in sonetPathCurrent table

      pwCepCfgIndex         = 9  -- Index of associated entry
                                   -- in pwCepCfg table (above)
   }



(page 8 continued on part 2)

Next RFC Part