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

List:       zebra
Subject:    [zebra 8631] Re: OSPF daemon API (Funcspec ideas)
From:       Ralph Keller <keller () arl ! wustl ! edu>
Date:       2001-05-30 21:57:57
[Download RAW message or body]

Hi Masahiko,

> 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?

You are completely right. I would like to have a complete copy of the LSDB so I
can run my own routing algorithm. And I would like to inject opaque LSAs to tell
other active routers about processing capabilities of a router. Thus, I would
like to inject opaque LSAs but be able to receive all LSAs (to reconstruct the
topology).

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

Well, I think we should be able to handle all LSA types. I know this might be
controversial but otherwise the API is useless for me since I have no means to
reconstruct the topology. But I think it should not be possible to inject LSAs
other than opaque type.

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

I think there should be a single connection between the client-side library and
the ospf daemon. All opaque types are handled over this connection. I think we
should make it as simple as possible (but not simpler ;-)

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

For now, I think the ospf daemon should reject registration requests for the
same opaque type. Otherwise we have to deal with all this contention management
which will be complicated. In a first step, registration should fail if an
application already registered this type.

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

Well, first I was thinking of using one-way communication (since we have a
reliable TCP/IP connection between the client library and ospf daemon). However,
if we consider all the error cases, then each indication or notification should
be acknowledged. But this will make the protocol more complicated.

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

I think the API calls should be blocking and return with the expected result or
an error code. If the peer does not send either the result or an error code, the
API call fails with a timeout. Since we are multiplexing messages over a single
connection, we need some sort of request/response matching scheme. To do that,
each sent message is tagged with a sequence number (which is incremented each
time) and a time stamp. For a two-way call, the caller sends a message and then
blocks until a response is received (or a timeout occurs).

> 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?

We use a new port (I used 2606) number for the TCP/IP connection between the
client and the OSPFd. The OSPF daemon acts as a server and accepts connections
on this port (like it does for the VTY).

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

For now, I think this is ok. Eventually, we need some sort of password
mechanism.

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

I am not completely sure what you mean by "session". In my idea, each
application has its own connection to the ospf daemon and can inject/receive
different opaque types over this connection. Do you mean with "session" the
handling of one specific opaque type?

- Ralph

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