Internet DRAFT - draft-allan-y1711-and-lsp-ping

draft-allan-y1711-and-lsp-ping




 Internet Draft                                              David Allan
 Document: draft-allan-y1711-and-lsp-ping-00.txt         Nortel Networks
 Category: Informational                                   February 2003

 
                           Y.1711 and LSP-PING

 
 Status of this Memo
 
    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.

    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."

    The list of current Internet-Drafts can be accessed at
         http://www.ietf.org/ietf/1id-abstracts.txt
    The list of Internet-Draft Shadow Directories can be accessed at
         http://www.ietf.org/shadow.html.
 
 Copyright Notice
 
    Copyright(C) The Internet Society (2003). All Rights Reserved.
 
 Abstract
 
    This internet draft shows that that the OAM tools defined by
    ITU-T SG13/Q3 and the IETF are complementary.
 
 Sub-IP ID Summary

    [to be removed when published]


    WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK

    Fits in the MPLS, PWE and PPVPN boxes.

    WHY IS IT TARGETED AT THESE WGs

    This draft shows that LSP-PING and Y.1711 can be considered to be
    complementary tools in the suite of options to measure and
    instrument MPLS.


    

    Allan et.al           Expires August 2003                   Page 1
   
                          Y.1711 and LSP-PING

 1. Introduction

    [Y1711] and [LSP-PING] are products of the ITU-T SG13/Q3 and the
    IETF MPLS WG respectively. Each is reflective of the design
    philosophies of the communities of their origin.

    The purpose of this draft is to compare and contrast design
    elements of the two approaches. The conclusion drawn is that the
    approaches are complementary and comprehensive instrumentation of
    MPLS is ultimately possible using both.

 2. Y.1711

    Y.1711 and its proposed extensions is primarily focused on fault
    management and availability measurement for MPLS. The major design
    objective of Y.1711 as it currently stands is fast, simple and
    automatic defect detection and handling.  A secondary goal is to be
    able to measure availability simply. It trades precision in fault
    isolation in return for this fast/simple/automatic defect
    detection/handling capability (frequently referred to as "bounded
    detection time"). This manifests itself in a number of design
    decisions:

    - The basic CV probe has been ruthlessly simplified to minimize
    processing. Frequent injection of CV probes into the network does
    not degrade the network. This manifests itself in a small number of
    fixed fields.

    Frequent injection of CV probes is a prerequisite for
    consistent/deterministic defect detection/handling and availability
    measurement. Injection of CV probes into LSPs from multiple sources
    (MP2P possibly with ECMP) is assumed to result in arrival rates at
    the LSP egress bursting at line rate.

    - The CV probe is augmented with defect notification PDUs, FDI for
    the forward direction, and BDI for the reverse direction. These are
    used for alarm suppression and control of performance measurement
    functions. BDI has limited applicability given that most LSPs are
    uni-directional, however it is very useful for interworking OAM
    with bi-directional PW clients (e.g. ATM).

    - A slightly more sophisticated probe type, the FEC-CV (under 
    study) can carry aggregated FEC information (in the form of a bloom 
    filter) such that a significant amount of configuration information 
    that is bound to the LSP can be verified in a single transaction. 
    Simple boolean operations on the bloom filter at the LSP
    egress can be used to detect misbranching while being tolerant of
    inbound filtering and other artifacts of network operations.

    - Probe processing is primarily performed at the egress such that
    for uni-directional LSPs, there is minimal ambiguity in detecting
    failure.  This is also required to take the appropriate consequent

    
    Allan                 Expires August 2003                 Page 2
   
                          Y.1711 and LSP-PING

    actions, eg to inform higher layer clients of lower layer failures
    and thus avoid generating alarm storms in inappropriate places, or
    perhaps suppress traffic if a security compromise is indicated (ie
    traffic arriving from the wrong source).

    - Probe processing provides a simple "pass/fail" indication and
    sufficient information to permit a craftsperson to initiate
    diagnosis. It is dependent on other tools to perform specific
    diagnosis and isolation of problems. For example either the basic
    CV (on p2p LSPs) or the FEC-CV (on mp2p LSPs) will identify
    misconfiguration and/or misbranching problems exist and permit the
    network to take some form of automated response, but will not
    identify the precise problem (in the case of the basic CV it will
    identify the source of the offending LSP).

    - Y.1711 is not designed to extract information from the network as
    to configuration and layout of network components. It does not
    currently define any path tracing functionality and only operates
    on LSP endpoints.

    - A corollary of the above, is that only LSP end points have any
    role in CV processing, and the CV probe passes transparently
    through intermediate nodes.

    - Y.1711 depends on some degree of ubiquitous deployment at the
    edge to maximize coverage of fault detection.

    - Y.1711 is primarily focused on tunnel end points. However core
    LSRs may add significant value by implementing a specific subset of
    Y.1711: FDI generation for P2P LSPs to provide alarm suppression
    and fault notification to the edge devices when failures in the
    core occur.

    And specific assumptions are made w.r.t. the evolution of the MPLS
    architecture:

    - OAM friendly LSP terminations will most likely deprecate PHP.
    This will:
      - Permit simple state association between OAM probes and paths,
      - Simplify verification of LSP function,
      - Permit verification to be at the granularity of LSPs instead of
        individual FEC elements,
      - Permit PW and VPN labels to be explicitly tested, and
        facilitate interworking with PW client OAM,
      - Simplify instrumentation of performance measurement.
      - allow consequent actions on defect detection to be enabled at
        the appropriate node,
      - allow a deterministic measurement of availability and QoS
        performance metrics at the appropriate node(the latter only
        have relevance when the LSP is "up" so it is important to be
        able to correctly specify this behavior).


    
    Allan                 Expires August 2003                 Page 3
   
                          Y.1711 and LSP-PING

    - Load balancing implementations will become friendly to reserved
    labels and preserve fate sharing between probes and traffic
    [GUIDELINES].

 3. LSP-PING

    LSP-PING is designed to be retrofitted to existing deployed
    networks and to exercise all functionality currently deployed. In
    order to do so, the design trade off is that detection or diagnosis
    of a problem may take an arbitrary number of transactions.

    Protocol complexity is tolerated as initial implementations will be
    in software. Protocol complexity manifests itself in the form of
    TLV encoding of key information (FEC stack elements, and downstream
    LSR label map, extracting ECMP specifics is still a topic of
    discussion). Future functionality may be added to the protocol via
    the definition of additional TLVs.  Protocol complexity also
    manifests itself from requiring all nodes to be able to process the
    probes.

    Aspects of the protocol design would permit a sparse subset to be
    handled in hardware (exact pattern match on the PDU). For example,
    in a VPN application, pinging a PE is facilitated by limiting the
    number of FECs at any level in the stack to one. Presumably an
    implementation of probe handling that matched on a ping of the PE
    loopback address could be optimized for that specific case.

    LSP-PING permits a uni-directional path to be tested from a single
    point, but depends on a reliable return path in order to propagate
    the test results back to the originating LSR. Therefore the
    protocol is designed to tolerate degrees of ambiguity in individual
    test results. Failure of an individual ping response may be due to
    any of several causes:
         - Forwarding path failure (including partial failure of ECMP
           or other load balancing constructs)
         - Return path failure
         - Port rate limiting at the egress
         - Port rate limiting at the ping origin
         - Congestive loss in the network

    And to deal with this ping supports several features to allow
    ambiguity to be eliminated via having the ingress perform
    variations of the original transaction:
         - Probe sequencing to permit both ingress and egress to detect
         gaps in probe sequences.
         - Return path may be specified permitting data plane and
         control plane problems to be distinguished.
         - Destination address may be manipulated to exercise payload
         sensitive ECMP implementations

    LSP-PING generally assumes PHP and that any specific LSP binding at
    the egress point of probe processing may not exist. From the
    perspective of reliable fault detection this is a minor issue as
    
    Allan                 Expires August 2003                 Page 4
   
                          Y.1711 and LSP-PING

    the use of a non-routable destination address limits any untested
    modes of failure. However this does alter the granularity of useful
    verification, as probe contents must be checked with the set of
    FECs associated with the LSR, rather than simply the set
    specifically associated with the LSP of interest. When testing a
    label stack for a VPN PE, the number of individual transactions
    required may be quite large as the number of FEC elements supported
    by the PE can be considerable.

    LSP-PING permits a label stack. For PW and VPN application, PHP may
    be employed by the PE such that PWs and VPN labels may not be
    directly tested (hence the FEC stack to permit transport or PSN
    probes to proxy verification for the transported application).

    LSP-PING has a traceroute mode that can extract a significant
    amount of information w.r.t. network configuration. Specifically
    all details of path construction for a given FEC (note that LSP-
    PING will most likely need to be augmented with authentication and
    authorization capability in the long term).

    No assumptions are made w.r.t. the evolution of the MPLS
    architecture.

 4. Summary

    LSP-PING and Y.1711 should be considered to be complementary.

    LSP-PING uses repeated transactions over time and the ability to
    encode specific FEC information to gain authoritative precision in
    testing. The PING/TRACEROUTE paradigm is suitable for employment by
    craftspersons (who frequently have the luxury of time to isolate
    and correct problems).

    Y.1711 uses simple periodic probes (basic CV), or information
    digests (FEC-CV) and egress probe processing to allow automatic
    fault detection/handling and thus minimize the time required to
    make an authoritative determination of the existence of a problem.
    This makes Y.1711 suitable for proactive fault detection and
    harmonizing MPLS operations and maintenance with many types of
    client layers.

 5. References

    [GUIDELINES] Allan, D., "Guidelines for MPLS Load Balancing", IETF
      Internet Draft, November 2002

    [LSP-PING] Pan et.al. "Detecting Data Plane Liveliness in MPLS",
      draft-ietf-mpls-lsp-ping-01, IETF work in progress, October 2002

    [Y1711] ITU-T Recommendation Y.1711, "OAM mechanism for MPLS
      networks"


    
    Allan                 Expires August 2003                 Page 5
   
                           Y.1711 and LSP-PING

 6.  Author's Address
    
    David Allan
    Nortel Networks              Phone: 1-613-763-6362
    3500 Carling Ave.            Email: dallan@nortelnetworks.com
    Ottawa, Ontario, CANADA

 7. Full Copyright Statement

    "Copyright (C) The Internet Society (2003). Except as set forth
    below, authors retain all their rights.

    This document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain it
    or assist in its implementation may be prepared, copied, published
    and distributed, in whole or in part, without restriction of any
    kind, provided that the above copyright notice and this paragraph
    are included on all such copies and derivative works.  However, this
    document itself may not be modified in any way, such as by removing
    the copyright notice or references to the Internet Society or other
    Internet organizations, except as needed for the  purpose of
    developing Internet standards in which case the procedures for
    rights in submissions defined in the IETF Standards Process must be
    followed, or as required to translate it into languages other than
    English.

    The limited permissions granted above are perpetual and will not be
    revoked by the Internet Society or its successors or assigns.

    This document and the information contained herein is provided on an
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
    REPRESENTS (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

















    
    Allan                 Expires August 2003                 Page 6