[prev in list] [next in list] [prev in thread] [next in thread] 

List:       zebra
Subject:    [zebra 8621] Re: OSPF daemon API (Funcspec ideas)
From:       endo () suri ! co ! jp (Masahiko Endo)
Date:       2001-05-30 10:40:01
[Download RAW message or body]

Hi Ralph,

> One thing to point out is that I not only need this API to inject and
> retrieve my own opaque LSAs but also retrieve the complete link state
> database (that is all LSAs). I need this in my project to reconstruct
> the network topology to run my own routing algorithm (which has some
> additional constraints that need to be fulfilled).

Until I read your last mail, I thought you are planning to provide
a new communication method to exchange external application data
embedded in opaque LSAs. In fact, your proposed ideas for API and
message formats are apparently focused onto opaque data handling.

I guess you are thinking not only to have control over opaque LSAs
but also try to make a complete copy of LSDB on your application,
and synchronize it with the ospfd, to perform your special routing
calculations, probably based on dynamically adaptive (loadable)
processing rules etc., right?

So, to clarify ourselves, let's consider functional specifications
before digging into API details etc. I believe it is impossible to
define concrete API specifications while its basic functionality is
not fixed. Please correct me if I am taking something badly.

After reading through your ideas and some days of consideration,
I wrote my assumptions and concerns that would affect the overall
design. Some issues will be complicated to solve, and some will be
quite trivial. I hope this will be a help of better understanding.

----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
Memorandum for functional specifications.

1) Scope of LSA types to handle

  This is very basic, but probably controversial, issue.
  I am still not sure if we should expand the specification to
  make it generic enough to be able to handle all LSA types, or
  to limit its capability to opaque data only.

2) Opaque-type handling

2-1) Opaque-type and connection mapping

  As illustrated below, there can be some variations in the way of
  communication for each application with the ospfd, and how each
  application specific datum would be handled.

      AP#1           AP#2            AP#3                  ospfd
    #--------+     #--------+      #--------+            #---------+
    | A      |     | B,C    |      | X,Y    |            | Z       |
    +--------+     +--------+      +--------+            +---------+
    | CliLib |     | CliLib |      | CliLib |            | SrvLib  |
    +--------+     +--------+      +--------+            +---------+
        A               A             A  A                 A A A A     USER
  ======|===============|=============|==|=================|=|=|=|==========
        |               |             |  |  type-X         | | | |   KERNEL
        |               |             |  +-----------------+ | | |
        |               |             |     type-Y           | | |
        |               |             +----------------------+ | |
        |               |                   type-B, C          | |
        |               +--------------------------------------+ |
        |                                   type-A               |
        +--------------------------------------------------------+

  The picture shows 4 situations all at once;

  *  AP#1 handles opaque type-A. This is the simplest form.

  *  AP#2 handles opaque type-B and C, and both are exchanged
     over a single link with ospfd 

  *  AP#3 handles opaque type-X and Y, and each are exchanged
     over separate links with ospfd 

  *  Ospfd handles opaque type-Z, within its built-in module.

  Note1: Here assumes type-A,B,C,X,Y,Z are different each other.
  Note2: There may be one special case; "empty" connection.

  My concern is, should we restrict each client-side library to
  communicate with the ospfd, only over a single connection or not.
  Though this seems a trivial matter, the decision will affect
  processing complexity such as communication error handling.

2-2) Opaque type contention avoidance

  As a natural consequence of above architecture, there must be
  some kind of opaque-type contention detecting mechanism, maybe
  at the time of initial registration.

  Now, change the previous assumption that type-A, B and Z might
  be the same value. Then we will encounter the following issues.

  *  Between applications.
     --> What if type-A and type-B is the same?

  *  Between an application and a built-in module.
     --> What if type-A and type-Z is the same?

  Should we leave an option to allow multiple instances that have
  the same opaque-type to communicate with the ospfd or not?
  If we decide to allow duplicated opaque-type registration, some
  kind of exclusive accessing mechanism must be provided to avoid
  interference problem. However, it could be useful to allow other
  applications to receive the exact same data from the ospfd.
  To say using the above example, while allowing AP#2 to set/get
  opaque data for type-B to/from the ospfd, AP#1 that handles
  type-A (=B) can "monitor" what AP#2 gets from the ospfd.

3) Type of communication

  It is unclear which message type will use which communication
  types; one-way (app -> ospfd, app <- ospfd) or two-way.

    App           ospfd     App           ospfd     App            ospfd
     |  Indicate    |        |   Request    |        |   Notify      |
     |------------> |        |------------> |        | <-------------|
     |              |        |              |        |               |
   t V              V        |   Response   |      t V               V
                             | <------------|
                           t V              V

  Possibly, each operation might be categorized as follows.

  < One-way: App -> ospfd >

    *  Opaque-type registration.
    *  Event mask registration.
    *  Originate/update/delete of self-originated LSAs.

  < One-way: App <- ospfd >

    *  State change (ism/nsm) notifications.
    *  Notifications of a timing that a self-originated LSA should
       be originated/updated/deleted.
    *  Notifications of a timing that an LSA received via network
       should be updated/deleted.
    *  Notifications of any error information.

  < Two-way >

    *  Information retrieve such as LSDB contents.

  However, when we think about error cases, especially those which
  detected at ospfd side, one-way "app->ospfd" case is useless.
  So, for the reliable atomic operation handling, we should treat
  these one-way operations as two-way, and should always confirm
  whether each operation was succeeded/failed.

  As a side effect of two-way communication, some points for API
  behavior must be considered, such as request/response matching,
  expiration timer, or blocking/non-blocking issues.

4) Connection management

4-1) Addressing

  I could not get from your descriptions whether the listen port
  on the ospfd will be newly assigned for this purpose or reuse
  the VTY port. Though 2606 (ospf6d) is used in your sample code?

  And how about the target host address? Are we going to allow
  client-library to connect to any ospfd in the network?

4-2) Connection open/close

  Generally speaking, it is expected that client-side library
  has responsibility to initiate and terminate the connection.
  Of course, there will be some cases that the connection is
  closed by ospfd, such as fatal error on the ospfd.

  If the connection is shared by multiple opaque-types, client-
  side library keeps track of each "session", and the connection
  should be closed when the last session is finished.

4-3) Error handling policy

  Followings are the list of possible errors on both sides.

  < Client-library side >

    *  API parameter error
    *  Processing error in client-side library
    *  Communication error while sending to the ospfd
    *  Communication error while receiving from the ospfd
    *  Malformed message received from the ospfd
    *  Connection closed by peer (ospfd's crush!)

  < Ospfd-library side >

    *  Communication error while receiving from the client-side library
    *  Malformed message received from the client-side library
    *  Processing error in ospfd-side library
    *  Processing error during OSPF protocol processing.
    *  Communication error while sending to the client-side library
    *  Connection closed unexpectedly (application's crush!)

  Here comes again the issue of opaque-type multiplexing method.
  Let's assume that an application which maintains some sessions
  with the ospfd. At a certain time, a serious error, related to
  one of opaque-types, occurred (on either side).
  Note that the error considering here is not the one occurred
  within the client-side library before talking to the ospfd.

  < Shared connection >

    If the error is detected by client-side, the library would try
    to keep the connection open until the last session finishes.
    On the contrary, if the ospfd-side detected the error, the
    ospfd-side library would shutdown the connection immediately,
    regardless to the remaining sessions. As an alternative idea,
    the library would never touch the connection and just perform
    cleanup procedures such as flushing of self-originated LSAs
    relating to the opaque-type.

  < Separate connections >

    In this case, it is relatively simpler if every opaque-type
    uses their own connection with the ospfd. Since each session
    is independent, either sides that detected the error can close
    the connection and start a series of cleanup sequences.

----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----

I think it is better to comment to your API ideas in another mail,
to follow mail transactions easier afterward.

Regards.
----------------------------------------------------------------------------
Masahiko ENDO / Surigiken Co.,Ltd., Tokyo, Japan

[prev in list] [next in list] [prev in thread] [next in thread]