Internet DRAFT - draft-balus-mh-pw-control-protocol

draft-balus-mh-pw-control-protocol



  

  PWE3 Working Group
  Internet Draft
  Expires: January 2006


  David McDysan                                     Florin Balus
  MCI                                               Mike Loomis
                                                    Jeff Sugimoto
  Yuichiro Wada                                     Nortel
  NTT Communications
                                                    Andy Malis
  Mike Duckett                                      Tellabs
  Bellsouth
                                                    Paul Doolan
  Yeongil Seo                                       Mangrove Systems
  Korea Telecom
                                                    Prayson Pate
  Chris Metz                                        Overture Networks
  Cisco Systems
                                                    Vasile Radoaca
  Ping Pan                                          Consultant
  Hammerhead Systems



                                                 July 2005


        Multi-Segment Pseudowire Setup and Maintenance using LDP


                draft-balus-mh-pw-control-protocol-02.txt


 Status of this Memo

    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.

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

    Balus et.al            Expires July 2006                    Page 1 

   Internet Draft   draft-balus-mh-pw-control-protocol-02  July, 2005



    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.








 Abstract

    [MS PWE3 Requirements] describes the requirements to allow a service
    provider to extend the reach of pseudo-wires across multiple
    domains. A Multi-Segment PW is defined as a set of two or more
    contiguous PW segments that behave and function as a single point-
    to-point PW.

    The current specification of the PW Architecture [PW ARCH] defines
    the PW as a single Segment entity, connecting the Attachment
    Circuits between two Ultimate PEs (U-PE). The current procedures for
    establishing a single segment PW (SS-PW) is described in [PW
    Control], where typically an LDP session is established between the
    ultimate PEs handling the Pseudowire End Service (PWES). No
    intermediate nodes, between the PEs, are aware of the PW.

    The purpose of this draft is to specify new LDP extensions, end to
    end signaling procedures to address the related requirements
    specified in [MS-PWE3 Requirements]. The proposed procedures follow
    the guidelines defined in [RFC3036bis] and enable the usage of
    addressing schemes (L2FECs) and other TLVs already defined for PWs
    in [PW Control].

    The solution described in the draft provides a MS-PW Operational
    Model, Signaling Procedures consistent with the regular (SS-)PWs, in
    order to enable seamless implementation, deployment. The resulting
    MS-PW building blocks accommodate and enhance LDP-VPLS, VPWS
    solutions with minimal changes in the Information Models and
    Software Modules related to the L2VPN functionality.








    Balus et.al.           Expires January 2006               Page 2 

   Internet Draft   draft-balus-mh-pw-control-protocol-02  July, 2005


 Table of Contents

 1.    Terminology...................................................3
 2.    Introduction and Scope........................................4
 3.    Relevant SS and MS-PW Architectures...........................4
 4.    Motivations and Resulting Design Requirements.................6
    4.1 Satisfy the MS-PW requirements in [MS PWE3 Requirements].....6
    4.1.1 Scalability and Inter-Domain Signaling and Routing.........6
    4.1.2 Signaling Requirements.....................................7
    4.2 Operational Consistency with SS-PWs..........................8
    4.2.1 Service Identification and Provisioning Models.............8
    4.2.2 OAM........................................................8
    4.3 Service Resiliency...........................................9
 5.    Information Model for Dynamic Signaling of MS-PWs.............9
    5.1 MS-PW TLV Design............................................10
 6.    Signaling Procedures.........................................12
    6.1 Ensuring both MS-PW directions traverse the same U/S-PEs....12
    6.2 LDP Signaling Walkthrough...................................13
    6.3 Using common LDP Signaling procedures for MS and SS-PWs.....15
    6.4 Determining the Next Signaling Hop..........................15
    6.4.1 Static Provisioning of the next-signaling-hop.............15
    6.4.2 "Discovery" Mechanisms for the next-signaling-hop.........16
 7.    Service Resiliency...........................................17
 8.    OAM Considerations...........................................17
    8.1 MS-PW Capabilities..........................................18
    8.1.1 PW Status Capability Negotiation..........................18
    8.1.2 VCCV Capability Negotiation...............................18
    8.2 PW Status Notification Operation............................18
    8.3 VCCV Operation..............................................18
 9.    Security Considerations......................................19
 10.   IANA Considerations..........................................19
 11.   Acknowledgements.............................................19
 12.   Appendix: Example of Signaling Procedures....................19
 13.   Full Copyright Statement.....................................21
 14.   Intellectual Property Statement..............................21
 15.   References...................................................21
 16.   Authors' Information.........................................22

 1. Terminology

    The terminology used in this document is consistent with the
    terminology used in [MS PWE3 Requirements]:

      . Ultimate PE (U-PE). A PE where the customer-facing ACs
         (attachment circuits) are bound to a PW forwarder. An ultimate
         PE is present in the first and last segments of a MS-PW.
 
     . Single-Segment PW(SS-PW). A PW setup directly between two U-PE
         devices. Each LSP in one direction of a SS-PW traverses one PSN
         tunnel that connects the two U-PEs.

    Balus et.al.           Expires January 2006               Page 3 

   Internet Draft   draft-balus-mh-pw-control-protocol-02  July, 2005


      . Multi-Segment PW (MS-PW). A static or dynamically configured
         set of two or more contiguous PW segments that behave and
         function as a single point-to-point PW. Each end of a MS-PW by
         definition MUST terminate on an U-PE.

      . PW Switching Provider Edge S-PE.  A PE capable of switching the
         control and data planes of the preceding and succeeding PW
         segments in a MS-PW. It is therefore a PW switching point for a
         MS-PW. A PW Switching Point is never both U-PE and S-PE for the
         same MS-PW. A PW switching point runs necessary protocols to
         setup and manage PW segments with other PW switching points and
         ultimate PEs.

      . PW Segment. A part of a Single-Segment or Multi-Segment PW,
         which is set up between two adjacent PE devices, U-PEs and/or
         S-PEs.

      . Extended LDP session (E-LDP). An LDP session established using
         targeted discovery mode [RFC3036bis]

 2. Introduction and Scope

    [MS PWE3 Requirements] describes the requirements to allow a service
    provider to extend the reach of pseudo-wires across multiple
    domains. A MS-PW is defined as a set of two or more contiguous PW
    segments that behave and function as a single point-to-point PW.

    The current specification of the PW Architecture [PW ARCH] defines
    the PW as a single Segment entity, connecting attachment circuits on
    exactly two PEs. The current procedures for establishing PWs are
    described in [PW Control], where typically an LDP session is
    established between the PEs handling the pseudowire end service
    (PWES). The LDP session is referred to as "targeted" because it uses
    a targeted discovery (via hello messages) to establish an LDP
    session between the two PEs exchanging the PW labels. The tandem
    nodes between the PEs are unaware of the PW and are only involved
    with establishing a PSN tunnel between the (U-)PEs.

    The purpose of this draft is to specify new LDP extensions and end
    to end signaling procedures to address the requirements specified in
    [MS PWE3 Requirements].

    The proposed procedures follow the guidelines defined in
    [RFC3036bis] and enable the reuse of existing addressing schemes
    (L2FECs) and other TLVs already defined for SS-PWs in [PW Control].

 3. Relevant SS and MS-PW Architectures

    The following two figures describe the reference models [MS PWE3
    Requirements] to support SS and MS-PW emulated services.

    Balus et.al.           Expires January 2006               Page 4 

   Internet Draft   draft-balus-mh-pw-control-protocol-02  July, 2005


             |<-------------- Emulated Service ---------------->|
             |                                                  |
             |          |<------- Pseudo Wire ------>|          |
             |          |                            |          |
             |          |    |<-- PSN Tunnel -->|    |          |
             | PW End   V    V                  V    V  PW End  |
             V Service  +----+                  +----+  Service V
       +-----+    |     | PE1|==================| PE2|     |    +-----+
       |     |----------|............PW1.............|----------|     |

       | CE1 |    |     |    |                  |    |     |    | CE2 |
       |     |----------|............PW2.............|----------|     |
       +-----+  ^ |     |    |==================|    |     | ^  +-----+
             ^  |       +----+                  +----+     | |  ^
             |  |   Provider Edge 1         Provider Edge 2  |  |
             |  |                                            |  |
       Customer |                                            | Customer
       Edge 1   |                                            | Edge 2
                |                                            |
                |                                            |
        Attachment Circuit (AC)                   Attachment Circuit(AC)
        native ethernet service                  native ethernet service

                    Figure 1: PWE3 Reference Configuration

    Figure 1 shows the PWE3 reference architecture [PWE3-ARCH]. This
    architecture applies to the case where a PSN tunnel extends between
    two edges of a single PSN domain to transport a PW with endpoints at
    these edges.

            Native  |<-----------Pseudo Wire----------->|  Native
            Layer2  |                                   |  Layer2
           Service  |    |<-PSN1-->|     |<--PSN2->|    |  Service
            (AC)    V                                   V   (AC)
              |     +----+         +-----+         +----+    |
    +----+    |     |UPE1|======== | SPE |=========|UPE2|    |    +---+
    |    |----------|.......PW1....|.........PW2...|---------|----|   |
    | CE1|    |     |    |         |     |         |    |         |CE2|
    +----+          |    |=========|     |=========|    |         +---+
         ^          +----+         +-----+         +----+         ^
         |     Provider Edge 1        ^         Provider Edge 2   |
         |     (Ultimate-PE1)         |          (Ultimate-PE2)   |
         |                    PW switching point                  |
         |           (Optional PW adaptation function)            |
         |                                                        |
         |<------------------- Emulated Service ----------------->|

                     Figure 2: MS-PW Reference Model



    Balus et.al.           Expires January 2006               Page 5

   Internet Draft   draft-balus-mh-pw-control-protocol-02  July, 2005


    Figure 2 extends this architecture to show a Multi-Segment case.
    UPE1 and UPE2 provide a Pseudowire from CE1 to CE2. Each UPE resides
    in a different PSN domain. A PSN domain may correspond to a single
    Provider's network or to a subset of nodes within a Provider
    network. A PSN tunnel extends from UPE1 to SPE across PSN1, and a
    second PSN tunnel extends from SPE to UPE2 across PSN2.

    PWs are used to connect the Attachment circuits (ACs) attached to
    UPE1 to the corresponding ACs attached to UPE2. The PW segment on
    the tunnel across PSN1 is switched to a PW segment in the tunnel
    across PSN2 at SPE to complete the Multi-Segment PW (MS-PW) between
    UPE1 and UPE2. S-PE is therefore a PW switching point node and will
    be referred to as the PW switching provider edge (S-PE). PW segments
    of the same MS-PW (e.g., PW1 and PW2) MUST be of the same PW type,
    but PSN tunnels (e.g., PSN1 and PSN2) can be the same or different
    technology.

    Note that although Figure 2 only shows a single S-PE, a PW may
    transit more than one S-PE along its path.


 4. Motivations and Resulting Design Requirements

    This section describes the motivations and highlights the
    architectural objectives of the proposal.

 4.1 Satisfy the MS-PW requirements in [MS PWE3 Requirements]

 4.1.1 Scalability and Inter-Domain Signaling and Routing

    If a MS-PW deployment extends to large and far reaching portions of
    one or more networks, mandating an E-LDP session between all
    switching points of a MS-PW may lead to a control plane scalability
    issue [MS PWE3 Requirements]. Some network topologies have a natural
    hierarchy, as described in the use cases section of [MS PWE3
    Requirements]. For example, multiple providers who wish to provide
    PWs that span two or more networks will likely have a relatively
    small number of gateway nodes as switching points (S-PE) that
    provide access to a larger number of end nodes (U-PE) forming a
    hierarchy. As another example, in some MPLS access network
    topologies, it is foreseeable that thousands or even tens of
    thousands of U-PE nodes may specify a small number of gateway nodes
    as switching points (S-PE) for access to the MPLS backbone, breaking
    the overall MPLS network into a well established hierarchy of MPLS
    "domains".

    In a more generic sense, [MS PWE3 Requirements] discusses a number
    of cases of a PW Service that has to span multiple domains: e.g.
    Inter-Provider, Inter-AS (same provider), MAN-WAN. In any of these


    Balus et.al.           Expires January 2006               Page 6 

   Internet Draft   draft-balus-mh-pw-control-protocol-02  July, 2005


    cases the interaction between domains is controlled by certain
    gateways with a specific set of requirements for each individual
    scenario.

    This proposal eliminates the requirement for an E-LDP session
    between every pair of U-PE nodes for which a PW is required while at
    the same time preserving the necessary end to end signaling
    properties. In doing so it alleviates the control plane scalability
    requirements described in the previous paragraphs. Our proposal
    enables the end to end PW signaling through a "chain" of (E-)LDP
    sessions, using a dynamically determined set of S-PEs. If the S-PE
    and U-PE are identified by IP addresses, then IP routing protocols
    can distribute information to facilitate dynamic selection of a set
    of PEs between a Source U-PE and a Destination U-PE based upon
    parameters (e.g., metric, TE constraints, BGP attributes). U-PE
    reachability information could be reduced by assignment of IP
    address prefixes and/or prefix aggregation by a routing protocol.

    There could also be some Inter-Provider scenarios where the U-PEs
    located in a certain Provider domain may not be permitted to
    communicate directly via an (E)-LDP session to a U-PE in a different
    domain for operational and security reasons. For other reasons
    (e.g., security, administrative, etc.) the local U-PE may have no
    knowledge of the IP address of the remote U-PE. The requirements for
    these valid scenarios are still being specified and it is not clear
    whether or not a solution for dynamic end to end signaling is
    required or even allowed.

    A solution for these scenarios is for further study.


 4.1.2 Signaling Requirements

    The signaling described in this proposal is based on extensions to
    [RFC3036bis] and [PW Control]. The new elements (section 6) provide
    a flexible model that permits interoperability with manual
    provisioning models, but also enable an end to end MS-PW to be
    established with minimal number of OSS touches, ideally only one as
    specified in [MS PWE3 Requirements]. Specifically, the proposal
    enables the dynamic creation of an end-to-end MS-PW that does not
    require any manual intervention at the S-PE nodes.

    This draft allows for either the same set of S-PE nodes to be
    traversed in each direction of the MS-PW, or a different set.

    [Segmented PW] specifies the case where the set of intermediate S-
    PEs is manually configured and the PW is stitched at these points by
    matching the L2FEC for each segment and associating this with the
    next segment. This case is not precluded by, and could interoperate


    Balus et.al.           Expires January 2006               Page 7 

   Internet Draft   draft-balus-mh-pw-control-protocol-02  July, 2005


    with, the method described in this document.

 4.2 Operational Consistency with SS-PWs

    In a Service Provider network it is understood that SS and MS-PWs
    will co-exist, possibly for an indefinite amount of time.
    Furthermore, it is foreseeable that existing SS-PWs may one day be
    forced to migrate to a MS-PW scenario for a number of reasons. In
    any case, it should be an advantage to vendors developing PW
    implementations as well as providers of PW services to minimize the
    differences between SS and MS-PWs. Operationally, the procedures for
    identifying (addressing), provisioning and troubleshooting a SS or a
    MS-PW should be similar.


 4.2.1 Service Identification and Provisioning Models

    [PW CONTROL] specifies that a PW is uniquely associated with a set
    of connection identifiers: i.e. PWID (& U-PE pair) for PWID FEC or
    AGI, AII1, AII2 for the Generalized ID FEC. This proposal reuses the
    same service identifiers as SS-PW (PWID and Generalized ID FEC) to
    identify MS-PWs.

    From a provisioning perspective, this proposal is consistent with
    the existing models for SS-PWs. For MS-PWs, both a single ended and
    double ended model are possible as defined by [L2VPN SIGN], with no
    user intervention required at any S-PE node.

    In a MS-PW scenario, the S-PE nodes are aware of the PW. In the case
    of PWID addressing, in order to reuse the service identifiers for
    SS-PWs, the unique association between the U-PE pair and the PWID
    FEC must be maintained when transiting through the S-PE nodes. In
    the Generalized ID case a PW is identified by <PE1, <AGI, AII1>,
    PE2, <AGI, AII2>> in one direction and by <PE2, <AGI, AII2>, PE1,
    <AGI, AII1>> in the reverse direction [L2VPN SIGN].

    This document proposes some extensions to LDP to address the
    requirements described above for consistent operational model across
    different PW types. The proposed solution re-uses the same L2FEC
    definitions as in [PW CONTROL] for identifying the virtual
    connections and a similar service provisioning model.

    The proposal does not preclude the use or support of existing Auto-
    discovery procedures (e.g. BGP-AD, RADIUS).

 4.2.2 OAM

    It is important to support the end to end PW OAM concepts already
    described in [VCCV] and [PW Control]. To meet this requirement, the


    Balus et.al.           Expires January 2006               Page 8 

   Internet Draft   draft-balus-mh-pw-control-protocol-02  July, 2005


    S-PE must participate in the negotiation of the PW OAM options and
    Status TLV.

    The current definition of PW OAM functions (e.g. VCCV (LSP-Ping,
    BFD)) [VCCV] are specified only for operation on a U-PE to U-PE
    basis.  This means that the concatenation of PW switching of S-PEs
    in MS-PW appears as a PSN tunnel to the PW OAM function.

    Support for PW OAM on a U-PE to S-PE, or S-PE to S-PE segment basis,
    will require changes in the OAM messages and procedures to indicate
    whether the OAM message is intended for the destination U-PE,
    intermediate S-PEs, or both.


 4.3 Service Resiliency

    Several MPLS mechanisms exist today, including procedures defined in
    [RFC3036bis], [MPLS FRR], [Grace RS] etc. This draft does not
    preclude the use of any of these mechanisms.
    From a MS-PW perspective, Service Resiliency refers to the ability
    to choose a backup path in case of failure of the existing MS-PW
    path (including S-PE failure or any segment failure) [MS PWE3
    Requirements].


 5. Information Model for Dynamic Signaling of MS-PWs

    In the current (SS) PW Architecture (see figure 1), the setup and
    maintenance of the PW connection is based on a direct, E-LDP Session
    between PE1 and PE2. As a result of the bidirectional nature of PWs,
    there is an association between the L2FEC, Source and Destination U-
    PEs. This association is derived from the information related to the
    (E-)LDP session between PEs and it is used as part of the end to end
    message exchange.

    In the case of a MS-PW (see figure 2), there is not an E-LDP session
    between U-PE1 and U-PE2. Instead two LDP Sessions are to be used to
    establish the MS-PW connection: LDP1 between U-PE1 and S-PE, LDP2
    between U-PE2 and S-PE.

    The procedures defined in [PW Control] can not be applied to achieve
    the end to end signaling of the MS-PW. Specifically:
      . the identity of the PW endpoints can no longer be derived from
         the attributes of the local LDP session
      . the PWID U-PE pair association is lost. PWID becomes globally
         unique
      . for the Generalized ID the direct association between PW and
         <<PE1, <AGI, AII1>, PE2, <AGI, AII2>> respectively <PE2, <AGI,
         AII2>, PE1, <AGI, AII1>> is lost.


    Balus et.al.           Expires January 2006               Page 9 

   Internet Draft   draft-balus-mh-pw-control-protocol-02  July, 2005


      . the forwarding of received Label Mapping (LM) messages is not
         allowed

    In order to support dynamic end to end signaling [MS PWE3
    Requirements], while maintaining a consistent operational model with
    SS-PW, there is a need to maintain the relationships between L2FEC
    and PW endpoints (as discussed above) that are lost when the direct
    LDP session is not available. This document proposes transporting
    the address of the Source and Destination U-PEs in the related LDP
    messages transiting through S-PE node(s). The L2FEC in combination
    with the source and destination U-PE information form unique PW
    endpoint identifiers; for example using the GID FEC, the TAI and
    destination U-PE information will be unique, similarly for the
    source U-PE and SAI information.

    This information could be transported in a number of ways: via new
    "fields" inserted in the existing Generalized ID FEC or via a new
    LDP TLV. Choosing one vehicle versus the other is orthogonal to the
    concepts described in this document as long as the Source and
    Destination information together with the corresponding L2FEC is
    explicitly carried in the signaling message and used to identify,
    route the PW signaling message from source to destination U-PE.

    We describe, in section 5.1, the details of the LDP TLV approach as
    it ensures backwards compatibility with existing deployments,
    offering support for both PWID and Generalized ID FECs.

    Details of the Generalized ID FEC usage is for further study


 5.1 MS-PW TLV Design

    We are introducing a new TLV, the Multi-Segment PW TLV, which is
    appended by the Source U-PE to the LDP messages related to a MS-PW.

    The following format is being proposed:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|0|     MS-PW TLV (TBD)       |       MS-PW TLV Length        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   (Source) U-PE (Mandatory)                   |
    |                             "                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 (Destination) U-PE (Mandatory)                |
    |                             "                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



    Balus et.al.           Expires January 2006               Page 10 

   Internet Draft   draft-balus-mh-pw-control-protocol-02  July, 2005


    - UF bits 00 - U equal 0 means that if the receiving PE does not
    understand the TLV, a notification must be returned to the message
    originator and the entire message must be ignored.

    - MS-PW TLV (TBD) - To be assigned by IANA. Identifies this TLV as a
    MS-PW. The presence of this TLV in LDP messages indicates this is a
    MS-PW.

    - MS-PW TLV Length - Specifies the total length in octets of the
    TLV.

    - Source U-PE (Mandatory) - The address of the originating U-PE
    (e.g. U-PE1). In most of the cases it carries the IP loopback
    address of the Source U-PE, although other address types - e.g.
    IPv6, NSAP - could be supported.
    This field is used by a MS-PW Network Element for maintaining the
    uniqueness of PWID FECs and, optionally, in single sided
    provisioning the discovery of the remote U-PE by the Destination U-
    PE. When double sided provisioning is used, it is used to verify the
    remote U-PE against the provisioned value.

    - Destination U-PE (Mandatory) - The address of the Destination U-PE
    (e.g. U-PE2)

    Its value could be provisioned at the Source U-PE or is determined
    as part of the single-sided provisioning behavior [L2VPN SIGN].

    The Destination U-PE address field is used to select the next hop
    through the MS-PW domains.

    The basic construct used to carry the Address of the Source and
    Destination U-PEs is the Prefix Element which is defined below:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Prefix Type  |     FLAGS     |     PreLen    |    Prefix     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                     Prefix (contd)                            ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    - Prefix Type - one octet quantity. It encodes the address type for
    the address prefix in the Prefix field. Initial formats supported
    are:
    - IPv4 0x01
    - IPv6 0x02
    - NSAP 0x03

    Addition of other formats (or combinations of existing ones) for


    Balus et.al.           Expires January 2006               Page 11 

   Internet Draft   draft-balus-mh-pw-control-protocol-02  July, 2005


    further study: for example, AS Numbers, URLs etc.

    - FLAGS - One octet field. The field is reserved for future use:
    i.e. MUST be set to zero when transmitting a message and MUST be
    ignored at the receiving PE.

    - PreLen
    One octet unsigned integer containing the length in bits of the
    address prefix that follows.

    - Prefix Value
    An address prefix encoded according to the Prefix type field, whose
    length, in bits, was specified in the PreLen field, padded to a byte
    boundary.


 6. Signaling Procedures

    The following are generic procedures for signaling of an MS-PW.

    Note that we are using throughout the next sections, examples based
    on existing IP Loopbacks (as U-PE addresses) and references to IP
    routing procedures.

    According to section 6.1 of [MS PW Requirements]: "MS-PWs are
    composed of SS-PW, and SS-PW are bi-directional, therefore both
    directions of a PW segment MUST terminate on the same S-PE/U-PE". In
    other words both directions of a MS-PW should traverse the same set
    of S-PEs/U-PEs.

    Next section introduces the concepts, procedures that ensure
    compliance of the solution described in this document with the above
    requirement. Note that should this requirement change (e.g. "MUST"
    to "MAY terminate [..]") to enable for diverse S-PEs paths, our
    solution could accommodate both options.


 6.1 Ensuring both MS-PW directions traverse the same U/S-PEs

    The proposed procedure is based on an "Ordered" establishment of the
    individual PW segments that belong to a certain MS-PW. In other
    words, the signaling is initiated only from the "originating" U-PE
    node (selected based on provisioned information at nodal/PW level).
    Any S-PEs or the other U-PE will not initiate a LM Message for the
    setup of a MS-PW until it receives an incoming LM message for that
    MS-PW.

    We will refer to the direction from the originating U-PE node to the
    other U-PE node as the "Forward" direction of a MS-PW. The Forward


    Balus et.al.           Expires January 2006               Page 12 

   Internet Draft   draft-balus-mh-pw-control-protocol-02  July, 2005


    direction describes the direction of the LDP label mapping messages
    rather than the direction of the user dataplane. The Reverse
    direction is the opposite logic, describing the direction towards
    the originating U-PE node.

    The following section first discusses the signaling in the "Forward"
    direction followed by a brief description of the deltas in the
    "Reverse" direction. Note that the flags from the destination U-PE
    field (see section 5.1) may be used to indicate directionality/
    behavior in determining the next-signaling-hop.


 6.2  LDP Signaling Walkthrough

    The following section focuses on the step by step, generic signaling
    procedures involved in the setup of a MS-PW. The procedures involved
    in discovery of Next Signaling Hop are referenced in section 6.4.

    1. The PW FEC (PWID or Generalized ID) and Destination U-PE is
      provisioned on both U-PEs. If single sided provisioning or auto
      discovery is used, the Destination U-PE needs only to be
      configured on one of the U-PEs.

    2. The originating U-PE builds the MS-PW TLV by inserting its local
      address in the Source U-PE field and the address of Destination
      U-PE in the Destination U-PE field. The MS-PW TLV and optional
      TLVs, (e.g. QOS TLV) are appended to the LM message which is sent
      to the Next Signaling Hop. The next signaling hop towards the dU-
      PE can be determined by referencing the PW end point information
      against the MS-PW information disseminated as per section 6.4.

    3. When the next signaling hop receives the LM message, it verifies
      a PSN tunnel exists to the upstream MS-PW NE. If a PSN tunnel is
      not available a label release message is sent. However if the S-
      PE and the next signaling hop are directly connected, with no P
      device between them, the PSN tunnel may not be necessary [PW
      Control].

    4. OAM parameters (VCCV, Status TLV support) are validated. If the
      request cannot be supported a label release message is sent to
      the upstream MS-PW NE.

    5. If QoS information* was included in the LM message, the local NE
      performs a CAC against the selected PSN Tunnel to requesting NE.
      If the CAC fails a label release message is sent. Alternatively,
      based on Service Provider choice an increase in the capacity of a
      PSN tunnel may be tried to accommodate the bandwidth requirements
      of the MS-PW.



    Balus et.al.           Expires January 2006               Page 13 

   Internet Draft   draft-balus-mh-pw-control-protocol-02  July, 2005



    6. If the Destination U-PE address does not equal the MS-PW NE
      address, a new label mapping message is generated and sent to the
      Next Signaling Hop, with the original L2FEC and MS-PW TLV,
      replacing just the value of the service label in the Label TLV
      with one from its own label space. Note that the S-PE should not
      comply with the text of section 5.2.3 of [PW Control] i.e. should
      not initiate a LM message in the opposite direction towards U-PE1
      ("Ordered" Mode). Go to step 3.

    7. When the Destination U-PE receives the LM message containing the
      MS-PW TLV (the value from the destination U-PE field matches the
      address of the local Network Element), it attempts to match the
      L2 FEC with its local provisioning.
         a) If the L2 FEC and the Source U-PE address do not match the
            local provisioning, a label release message is sent.

         b) If the L2 FEC is not provisioned, the label maybe retained
            by virtue of liberal label retention

    8. The remaining Destination U-PE processing of the PW label mapping
      message is as defined in PWE3 control signaling standard [PW
      Control] (see also tasks outlined in steps 3-5). This completes
      the Signaling in the Forward direction.

    9. MS-PW Signaling in the Reverse direction starts. The (new) source
      U-PE and subsequently the S-PEs in the Reverse direction will
      perform the tasks described in steps 2-8. 

      The next hop at any S-PE is determined by referencing the LDP 
      sessions used to setup the LSP in the Forward direction. The 
      particular LDP Session is determined using the index (dU-PE,
      TAI/PWID) information from the LM message received from the 
      Reverse direction. The association between (L2FEC, sU-PE, dU-PE) 
      and the incoming LDP session is stored as the PW Segments are 
      established. This information is always required for further 
      Control Plane Exchanges (e.g. Label Release, PW Status) but is 
      used to also setup the MS-PW in the Reverse direction.

    * The term "QoS Information" is used here to mean either one or both
    of Quantity (e.g. Bandwidth) and/or Quality (e.g. DiffServ) of
    Service. The detailed definition of the TLVs used to signal this
    information is outside the scope of this document. Description of
    possible TLV structures could be found in [TSPEC] and respectively
    [RFC3270].






    Balus et.al.           Expires January 2006               Page 14 

   Internet Draft   draft-balus-mh-pw-control-protocol-02  July, 2005


 6.3 Using common LDP Signaling procedures for MS and SS-PWs

    In addition to the OSS and Operational consistency between SS [PW
    Control] and MS-PWs concepts described in this document, it would be
    preferable to have consistent procedures used in the Network
    Elements in order to minimize implementation deltas.

    If the U/S-PEs support the signaling procedures described in the
    previous section for MS-PWs, then these Network Elements could use
    consistent procedures to establish also SS-PWs between them.

    In this context it is important to note that steps 1-9 are the same
    for both SS/MS-PWs. The only difference between a SS/MS-PW is the
    amount of times the procedure cycles through steps 3-6: i.e. in the
    SS-PW case, the first receiving PE (see step 6) will determine that
    the destination U-PE is itself and the source U-PE is the same with
    the originator of the LDP session on which the LM message was
    received. As a result it will run right away through the remaining
    of the steps (7-9) instead of cycling 1/more times through steps 3-6
    as for a MS-PW.


 6.4 Determining the Next Signaling Hop

    To support end-to-end dynamic signaling of MS-PWs, information must
    be present in MS-PW aware nodes to support the determination of the
    next signaling hop. Such information can be provisioned on each MS-
    PW system or disseminated via regular routing protocols (e.g. BGP).

    The following section describes procedures that could be used to
    "discover" the next-signaling-hop in MS-PW aware systems.

 6.4.1 Static Provisioning of the next-signaling-hop

    The simplest way to build next-signaling-hop knowledge is by static
    provisioning. The provisioning of the next-signaling-hop (e.g. S-PE)
    is similar to the way IP static routes/default gateways are
    provisioned: e.g. in a U-PE at the nodal level, a default S-PE is
    provisioned manually when the MS-PW feature is enabled. This can be
    a simple and effective method, when the network topology is simple
    and well defined.

    As long as the U-PE prefixes from one domain can be summarized the
    static method could be also expanded to entire domains: i.e. all the
    U-PEs in one domain being represented by 1/just a few static entries
    of this sort: U-PE Prefix (47.0.0.0/8), NH = S-PE1. At the other
    extreme, when special treatment is required for a certain PW a
    "fully qualified" entry could be provisioned: e.g. AGI (40),U-PE1
    (47.1.1.1), AII (200) -> NH (S-PE1).


    Balus et.al.           Expires January 2006               Page 15 

   Internet Draft   draft-balus-mh-pw-control-protocol-02  July, 2005


    Note that static provisioning may be used in combination with
    dynamic discovery. Indeed, some PW domains may use static
    provisioning while other PW domains along the multi-hop signaling
    path may use dynamic discovery within their domain. An example of
    this scenario is where many U-PEs in a given network will always use
    a well known primary and backup S-PE "gateways" as the next hop.
    This S-PE gateway may have many possible S-PE peers and may use a
    dynamic discovery mechanism to determine the next-signaling-hop of
    its S-PE peer for a given MS-PW.


 6.4.2 "Discovery" Mechanisms for the next-signaling-hop

    The next-signaling-hop selection can also be determined by
    dynamically learning, for each PW Domain, the association between
    the (Destination U-PE and optionally TAI/PWID) and the next-
    signaling-hop.

    There could be several mechanisms that allow dynamic discovery,
    advertisement of the next-signaling-hop. The focus of this section
    is on how this can be accomplished with BGP-based procedures. Note
    that these procedures may have an end-to-end scope (e.g. Inter-AS
    Use Case) or may be limited just to the <Core> PW Domain (e.g. MAN-
    WAN Use Case), depending upon the availability of BGP in the related
    MS-PW capable nodes.

    The signaling procedures described in this draft are compatible and
    make use of the L2VPN provisioning models and related AD procedures
    described in [L2VPN SIGN] and respectively [BGP AD].

    If the Source U-PE knows apriori the address of the Destination U-
    PE, there is no need to advertise a "fully qualified" address on a
    per PW Attachment Circuit. The Destination U-PE may
    advertise only its Prefix address (and not the Attachment <Circuit>
    Identifier (AI)) as part of well known BGP auto-discovery procedures
    - see [BGP AD], [L2VPN SIGN].

    As PW Endpoints are provisioned in the U-PEs, the Source U-PE will
    use this information to obtain the first S-PE hop (i.e., first BGP
    next hop) where the first PW segment will be established and
    subsequent S-PEs will use the same information (i.e. the next BGP
    next-hop(s)) to obtain the next-signaling-hop(s) on the path to the
    Destination U-PE.

    This is not an exhaustive list, merely examples of how discovery can
    be accomplished using BGP. It can also be envisioned, in some
    particular scenarios, that IGP with TE extensions could be used to
    control the selection of the next-signaling-hop, while avoiding non
    MS-PW aware devices (e.g. Ps, 2547 PEs).


    Balus et.al.           Expires January 2006               Page 16 

   Internet Draft   draft-balus-mh-pw-control-protocol-02  July, 2005


 7. Service Resiliency

    With the introduction of dynamic determination of the intermediate
    S-PEs, this proposal introduces the possibility of end to end (as
    well as segment) connection resiliency for MS-PWs.

    For failures between MS-PW elements, this document does not preclude
    any existing MPLS failure recovery mechanisms from being used (i.e.
    [MPLS FRR]).

    For failures that prevent one MS-PW system from establishing a PW
    segment to the succeeding MS-PW system (e.g. U-PE to S-PE), this
    document adopts the procedures described in section 6 to allow for
    the dynamic selection of intermediate next hops for the purpose of
    service resiliency. For example, a source U-PE node can select a
    candidate S-PE next hop via local preference (or via any other
    metrics) for the purpose of service resiliency.

    Several options are possible for service resiliency and a simple
    example is provided here, with further optimizations to be explored
    in future revisions of the document. Existing MPLS or PSN tunnel
    recovery mechanisms must be attempted before the procedures
    described below.

    As a result of the MS-PW following the same forward and reverse
    path, we propose that only the upstream node from the failure in the
    forward path make the next hop selection. This provides consistency
    with the procedures used to establish the original MS-PW (described
    in section 6), where the forward path determines the backwards path
    as well. Recall that each MS-PW system is already aware of the
    direction of the MS-PW signaling, and its relation to that direction
    for any particular MS-PW L2 FEC, sU-PE, dU-PE triplet. The MS-PW
    segments downstream from the failure MUST be released as a new path
    may be selected that does not overlap with the previous path.

    If alternate routing is not possible at the closest MS-PW node
    upstream from the failure, that node must release the PW segment to
    the next upstream MS-PW system to attempt additional rerouting.


 8. OAM Considerations

    This section deals with the Negotiation of the OAM Capabilities
    described in [VCCV], where the OAM functions (e.g. VCCV (LSP-Ping,
    BFD)) are specified only for operation on a U-PE to U-PE basis.

    Support for PW OAM on a U-PE to S-PE, or S-PE to S-PE segment basis,
    require changes in the OAM messages and procedures to indicate
    whether the OAM message is intended for the destination U-PE,


    Balus et.al.           Expires January 2006               Page 17 

   Internet Draft   draft-balus-mh-pw-control-protocol-02  July, 2005


    intermediate S-PEs, or both. These changes are for further study.

 8.1  MS-PW Capabilities

    Common OAM capabilities should be supported on all U-PE and S-PE
    nodes in the MS-PW.  MS-PW takes a least common denominator approach
    to OAM.  The minimum OAM functionality supported on a MS-PW is label
    withdraw.

 8.1.1 PW Status Capability Negotiation

    PW Status capability is negotiated across the MS-PW when the MS-PW
    is first setup.  Support for PW status notification is indicated by
    the presence of the status TLV in the label mapping message.

    PW Status capability negotiation at the U-PE occurs as described in
    [PWE3 CNTL].

    It is strongly recommended that MS-PW implement PW status TLV.

 8.1.2 VCCV Capability Negotiation

    VCCV capability is negotiated across the MS-PW when the MS-PW is
    first setup.  Support for VCCV is indicated by the presence of the
    VCCV parameter in the interfaces parameter TLV.  This parameter is
    included in the label mapping message within the parameter TLV as
    described in [VCCV]

    VCCV capability negotiation at the U-PE occurs as described in
    [VCCV]

    An S-PE successfully negotiates VCCV capability for the MS-PW when
    it support VCCV itself and the label mapping messages from its
    upstream and downstream neighbors indicate support for VCCV for a
    given MS-PW FEC.

 8.2  PW Status Notification Operation

    PW Status notification at the U-PE occurs as described in [PWE3
    CNTL].

    When an S-PE receives a PW status notification message, the message
    is processed at the S-PE and propagated down stream along the
    control path.

 8.3  VCCV Operation

    VCCV operation at the MS-PW Network Element (NE) occurs as described
    in [VCCV], with the S-PEs transparently forwarding these messages


    Balus et.al.           Expires January 2006               Page 18 

   Internet Draft   draft-balus-mh-pw-control-protocol-02  July, 2005


    towards the destination U-PE.

    Support for MS-PW segment OAM, trace-route is for further study.


 9.  Security Considerations

    To be addressed later.


 10. IANA Considerations

    A new TLV code point needs to be allocated by IANA for MS-PW TLV.


 11. Acknowledgements

    The editors gratefully acknowledge the following contributors: Luca
    Martini, Nabil Bitar, Richard Spencer, Simon Delord, Bruce Davie,
    Elizabeth Hache, Hamid Ould-Brahim, Praveen Muley, Arashmid
    Akhavain.


 12. Appendix: Example of Signaling Procedures

    The following section discusses an example of an end to end
    signaling walkthrough for a MS-PW using the architecture depicted in
    Figure 2.

    Let us assume that Double-sided provisioning and Generalized ID FEC
    are being used to set up the MS-PW built using segments PW1 and PW3
    and using LDP1 and LDP2 sessions.

    Here are the required steps:

    1. Service Provisioning
         a) at U-PE1: AGI = 40, SAII=100, TAII=200, Remote PE = U-PE2
            (IP2 loopback), Origin = Yes
         b) at U-PE2: AGI = 40, SAII=200, TAII=100, Remote PE = U-PE1
            (IP1 loopback);

    2. The originating U-PE (U-PE1 in our example) builds the MS-PW TLV
      by inserting its loopback address in the Source U-PE field and
      the address of U-PE2 in the Destination U-PE field. Next it
      appends the MS-PW TLV to the label mapping message associating
      the provisioned FEC information - i.e. (40,100,200) - with the
      corresponding PW service label.




    Balus et.al.           Expires January 2006               Page 19 

   Internet Draft   draft-balus-mh-pw-control-protocol-02  July, 2005


    3. Using the address of Destination U-PE (U-PE2), U-PE1 selects the
      next signaling hop (S-PE) determined by referencing the PW end
      point information - IP2,40,200 - against the MS-PW information
      disseminated as per section 6.4.

    4. On receipt of the LM message, S-PE performs the following tasks:
      Verifies it has a PSN tunnel to U-PE1. If no tunnel is found a
      label release message is sent.

         a) Verifies it can support the requested OAM parameters (VCCV,
            Status TLV support). If the request cannot be supported a
            label release message is sent to U-PE1.

         b) If QoS information* was included in the LM message, it
            performs a CAC against the selected PSN Tunnel to U-PE1. If
            the CAC fails a label release message is sent to U-PE1.
            Alternatively, based on Service Provider choice, an
            increase in the capacity of the PSN tunnel may be tried to
            accommodate the bandwidth requirements of the MS-PW.

         c) Checks to see if it is the Destination U-PE by comparing
            the address within the MS-PW TLV d-UPE field with its own
            address. If the addresses are not the same, S-PE looks for
            a next signaling hop to get to U-PE2 - see step 3 above.
            Then it signals the final segment of the MS-PW by
            generating and forwarding a new label mapping message to U-
            PE2, with the original L2FEC (40,100,200) and MS-PW TLV
            (IP1, IP2), replacing just the value of the service label
            in the Label TLV with one from its own label space.

    5. When U-PE2 receives the LM message containing the MS-PW TLV, it
      performs tasks outlined in step 4.

    6. U-PE2 then attempts to match the L2 FEC with its local
      provisioning.
         a) If the FEC information and the U-PE1 address do not match
            the local provisioning, a label release message is sent.
         b) If the FEC information (40,200,100) is not yet provisioned,
            the label may be retained by virtue of liberal label
            retention.

    7. The remaining U-PE2 processing of the PW label mapping message is
      defined in PWE3 control signaling [PW Control].

    8. MS-PW Signaling in the Reverse direction U-PE2 to U-PE1 starts.
      The U-PE2 and subsequently S-PE will perform the tasks described
      in steps 2-7. The next hop at U-PE2 and S-PE is determined by
      referencing the LDP sessions used to setup the LSP in the Forward
      direction. The particular LDP Session is determined in the U-PE2


    Balus et.al.           Expires January 2006               Page 20 

   Internet Draft   draft-balus-mh-pw-control-protocol-02  July, 2005

      and S-PE using the index (IP1,TAI(40,100)) from the LM message
      received from the Reverse direction.

 13. Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (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.

14. Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

 15. References

    [RFC3036bis] Andersson, Minei, Thomas. "LDP Specification" draft-

    Balus et.al.           Expires January 2006               Page 21 

   Internet Draft   draft-balus-mh-pw-control-protocol-02  July, 2005

    ietf-mpls-rfc3036bis-01.txt, IETF Work in Progress, November 2004
    [MS PWE3 Requirements] Martini et al. "Requirements for inter domain
    Pseudo-Wires", draft-ietf-pwe3-ms-pw-requirements-00.txt, IETF Work
    in Progress, June 2005

    [PW Control] Martini et.al. "Pseudowire Setup and Maintenance using
    LDP", draft-ietf-pwe3-control-protocol-17.txt, IETF Work in
    Progress, June 2005

    [VCCV] Nadeau et.al., "Pseudo Wire (PW) Virtual Circuit Connection
    Verification (VCCV)", draft-ietf-pwe3-vccv-03.txt, June 2004

    [L2VPN SIGN] Rosen et. al. "Provisioning Models and Endpoint
    Identifiers in L2VPN Signaling", draft-ietf-l2vpn-signaling-03.txt,
    IETF Work in Progress, February 2005

    [Segmented PW] Martini et.al. " Segmented Pseudo Wire", draft-ietf-
    pwe3-segmented-pw-00.txt, IETF Work in Progress, July 2005

    [RFC3270] Le Faucheur, et. al. "MPLS Support of Differentiated
    Services", RFC 3270, May 2002

    [TSPEC] Wroclawski, J. "The Use of RSVP with IETF Integrated
    Services", RFC 2210, September 1997

 16. Authors' Information

    Andrew G. Malis
    Tellabs, Inc.
    2730 Orchard Parkway
    San Jose, CA, USA 95134
    Email: Andy.Malis@tellabs.com

    Chris Metz
    Cisco Systems, Inc.
    3700 Cisco Way
    San Jose, Ca. 95134
    Email: chmetz@cisco.com

    David McDysan
    MCI
    22001 Loudoun County Pkwy
    Ashburn, VA, USA 20147
    dave.mcdysan@mci.com

    Florin Balus
    Nortel
    3500 Carling Ave.
    Ottawa, Ontario, CANADA
    balus@nortel.com


    Balus et.al.           Expires January 2006               Page 22 

   Internet Draft   draft-balus-mh-pw-control-protocol-02  July, 2005

    Jeff Sugimoto
    Nortel
    3500 Carling Ave.
    Ottawa, Ontario, CANADA
    sugimoto@nortel.com

    Mike Duckett
    Bellsouth
    Lindbergh Center
    D481
    575 Morosgo Dr
    Atlanta, GA  30324
    e-mail: mduckett@bellsouth.net

    Mike Loomis
    Nortel
    600, Technology Park Dr
    Billerica, MA, USA
    mloomis@nortel.com

    Paul Doolan
    Mangrove Systems
    IO Fairfield Blvd
    Wallingford, CT, USA 06492
    pdoolan@mangrovesystems.com

    Ping Pan
    Hammerhead Systems
    640 Clyde Court
    Mountain View, CA, USA 94043
    e-mail: ppan@hammerheadsystems.com

    Prayson Pate
    Overture Networks, Inc.
    507 Airport Blvd, Suite 111
    Morrisville, NC, USA 27560
    Email: prayson.pate@overturenetworks.com

    Yuichiro Wada
    NTT Communications
    3-20-2 Nishi-Shinjuku, Shinjuke-ku
    Tokyo 163-1421, Japan
    yuichiro.wada@ntt.com

    Yeongil Seo
    Korea Telecom Corp.
    463-1 Jeonmin-dong, Yusung-gu
    Daejeon, Korea
    syi1@kt.co.kr



    Balus et.al.           Expires January 2006               Page 23