[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Savannah-hackers] savannah.gnu.org: submission of openvnet
|
From: |
gsun |
|
Subject: |
[Savannah-hackers] savannah.gnu.org: submission of openvnet |
|
Date: |
Mon, 29 Oct 2001 13:15:39 -0500 |
A package was submitted to savannah.gnu.org.
This mail was sent to address@hidden, address@hidden
Gary L. Sun <address@hidden> described the package as follows:
License: other
Other License: Reservation for now, might change later. I am looking
for a real free software license, not just coding but
freedom to have the choice not to compliant to GNU/GPL/GXX.
But, reserve all rights at the same time.
Package: openvnet
System name: openvnet
This package does NOT want to apply for inclusion in the GNU project
As detailed as possible. Is still under evolution.......
(c) 2001. All Rights Reserved.
Gary L. Sun
===========================================================
OpenVNET .VNET Frame Work
Table Of Contents
1. Abstract
2. Conventions used in this document
3. .VNET Overview
3.1 .VNET Architectural Components
3.1.1 .VNET Webservice Protocol (.VNETWP)
3.1.2 .VNET Client
3.1.3 OpenVNET .VNET Local Daemon
3.1.4 OpenVNET .VNET Databank Info Server
3.1.5 .VNET Service Server
3.1.6 .VNET Management station
3.1.7 .VNETP
3.1.8 .VNETCP
3.2 OpenVNET .VNET Functional Components
3.2.1 Name Registration Service
3.2.2 Discovery Domain and Login Control Service
3.2.3 State Change Notification Service
3.2.4 CDSA security infrastructure (TBS)
3.2.5 Secured Databank Info Service (TBS, Barry -- may be ?)
3.3 OpenVNET and Domain Name System (DNS)
3.4 OpenVNET .VNET and LDAP
3.5 OpenVNET Local Daemon Discovery
3.6 OpenVNET .VNET and NAT
3.7 Interactions Between OpenVNET .VNET Local Daemon Infrastructures
3.8 Deployment Architecture Diagram
4. OpenVNET .VNET Object Model
4.1 NETWORK ENTITY Object
4.2 .VNET LOCAL DAEMON Object
4.3 DIRECTORY Object
4.4 NODE Object
4.5 DISCOVERY DOMAIN Object
4.6 DISCOVERY DOMAIN SET Object
4.7 TOKEN Object
4.8 WEBSERVICE Object
4.9 SERVICE SERVER Object
4.10 DATABANK INFO SERVER Object
4.11 NODE Object
4.12 .VNET CLIENT Object
4.13 .VNET VIRTUAL IDENTITY Object
4.14 .VNET
4.7 OpenVNET Database Model
5. OpenVNET Implementation Requirements
5.1 OpenVNET .VNET Local Daemon Requirements
5.1.1 Required Attributes for Support of OpenVNET .VNET Local Daemon
5.1.2 Attribute Descriptions for OpenVNET .VNET Local Daemon
5.1.3 OpenVNET .VNET Local Daemon Gateway Attribute Requirements
5.1.3.1 Port_ID_Token
5.1.4 Example OpenVNET .VNET Local Daemon Object Model Diagram
5.1.5 Required Commands and Response Messages for Support of OpenVNET .VNET
Local Daemon
5.2 NODE Requirements
5.3 Attribute Descriptions for Discovery Domain Registration
5.4 Use of TCP For OpenVNET .VNET Communication
5.5 Use of UDP For OpenVNET .VNET Communication
6. OpenVNET .VNET Message Attributes
6.1 OpenVNET .VNET Attribute Summary
6.2 Virtual Entity Identifier-Token Keyed Attributes
6.2.1 Virtual Entity Identifier (VEID)
6.2.2 Virtual Entity Protocol
6.2.3 Management IP Address
6.2.4 Entity Registration Timestamp
6.2.5 Protocol Version Range
6.2.6 Registration Period
6.2.7 Entity Certificate
6.3 .VNET LOCAL DAEMON-Token Keyed Attributes
6.3.1 .VNET LOCAL DAEMON IP-Address
6.3.2 .VNET LOCAL DAEMON TCP/UDP Port
6.3.3 .VNET LOCAL DAEMON Token
6.3.4 Entity Status Inquiry Interval
6.3.5 ESI/SCN UDP Port
6.3.6 .VNET LOCAL DAEMON Delegating Group
6.3.7 .VNET LOCAL DAEMON Certificate
6.4 OpenVNET .VNET WEBSERVICE Object Node-Keyed Attributes
6.4.1 OpenVNET .VNET WEBSERVICE Object Node Port Name
6.4.2 OpenVNET .VNET WEBSERVICE Object Node Port ID Token
6.4.3 OpenVNET .VNET WEBSERVICE Object Node Port Type Token
6.4.10 OpenVNET .VNET WEBSERVICE Object Descriptor
6.4.11 OpenVNET .VNET WEBSERVICE Object Features
6.4.5 OpenVNET .VNET WEBSERVICE Object Node Name
6.4.4 OpenVNET .VNET WEBSERVICE Object Node Name Token
6.4.14 OpenVNET .VNET WEBSERVICE Object Node Type
6.4.14 OpenVNET .VNET WEBSERVICE Object Node Type Token
6.4.12 OpenVNET .VNET WEBSERVICE Object Node SCN Bitmap
6.4.13 OpenVNET .VNET WEBSERVICE Object Node Certificate
6.4.6 OpenVNET .VNET WEBSERVICE Object Proxy Node
6.4.7 OpenVNET .VNET WEBSERVICE Object Proxy IP Address
6.4.8 OpenVNET .VNET WEBSERVICE Object Proxy Class of Service (COS)
6.4.9 OpenVNET .VNET WEBSERVICE Object Ptoxy Types
6.5 OpenVNET .VNET NODE Node-Token Keyed Attributes
6.5.1 OpenVNET .VNET NODE Node Name
6.5.2 OpenVNET .VNET NODE Node Name Token
6.5.3 OpenVNET .VNET NODE IP Address
6.5.4 OpenVNET .VNET NODE Initial Process Associator (IPA)
6.5.5 OpenVNET .VNET NODE Object Certificate
6.6 Other Attributes
6.6.1 Type Code
6.6.2 Preferred ID
6.6.3 Assigned ID
6.6.4 Space_Identifier
6.7 Discovery Domain Registration Attributes
6.7.1 OpenVNET Discovery Domain Attribute Summary
6.7.2 DD Set ID Token Keyed Attributes
6.7.2.1 Discovery Domain Set ID (DDS ID)
6.7.2.2 Discovery Domain Set Token
6.7.2.3 Discovery Domain Set Status
6.7.2.4 Discovery Domain Set Member
6.7.3.1 Discovery Domain ID (DD ID)
6.7.3.2 Discovery Domain Token
6.7.3.3 Discovery Domain SERVICE SERVER Node Member
6.7.3.4 Discovery Domain NODE Object Node Member
6.8 Vendor-Specific Attributes
6.9 Company OUI
7. .VNETP Message Format
8. Security Infrastructure
8.1 Data Integrity and Authentication
8.2 Confidentiality
8.3 Security Model
<!-- ===================================================== -->
OpenVNET .VNET Frame Work
1. Abstract
This document provides a preliminary framework (OpenVNET .VNET) (referred to
as .VNET hereinafter) centering around use of the OpenVNET Distributed
Virtual Execution Environment. It supports the use of OpenVNET Virtual Identity
and Resource Messageing System for discovery and management of OpenVNET
Databank Info Servcie and Webservice Local Daemon in any IP network, and the
frame work for OpenVNET Service Server, as a integrated application.
.VNET is an application that stores and manage the use of OpenVNET Token
System across OpenVNET Distributed Virtual Execution Environment, including
support of Local Daemon, Databank Info Server, and Service Server token
attributes, and monitors their availability, scalability, and reachability in
an integrated IP network.
Due to its role as a consolidated information repository and management
agency, .VNET provides for more efficient, scalable, and secured management of
peer-to-peer and client-server interchange of data in an IP network.
2. Conventions used in this document
.VNET refers to the framework consisting of the network model
and associated services.
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 RFC-2119 [2].
All IP frame formats are in big endian network byte order.
3. .VNET Overview
The objective of .VNET is to facilitate scalable configuration and secure
management of participating elements in an IP network. A OpenVNET .VNET
implementation MAY provide support for one or any number of .VNET as desired by
the implementer.
When used to support heterogeneous network, .VNET can be implemented to
facilitate the discovery and management of OpenVNET Token System based network
and with a gateway layer to support mapping from other identification system
into DitGNU Token System in an integrated IP environment.
3.1 .VNET Architectural Components
3.1.1 .VNET Protocol (.VNETP)
The .VNET Protocol (.VNETP) is a flexible and lightweight protocol
that specifies how .VNET clients and .VNET Local Daemons communicate.
3.1.2 .VNET Client
.VNET clients initiate transactions through the OpenVNET Webservice to
OpenVNET Local Daemon using the .VNETP. OpenVNET Webservice clients are
applications that are co-resident in the user\'s computing service, and can
register its attribute (service tokens) information in OpenVNET Token System
format to OpenVNET Local Daemon.
3.1.3 .VNET OpenVNET Local Daemon
The OpenVNET Local Daemon intercepts requests and responses from/to
Webservice(s) and provides services to regsitered Webservice(s) from other
registered OpenVNET Local Daemon and any registered token from the OpenVNET
Databank Info Server(s). Before a Webservice can send its requests and receive
services with OpenVNET Local Daemon, registered token(s) must be made available
to the OpenVNET Local Daemon and stored in a common DD, and then OpenVNET Local
Daemon will make the registered token(s) available to other OpenVNET Local
Daemons requesting services. OpenVNET Local Daemon also receive asynchronous
notification of topology .VNETs that occur in their DD(s). The DD will be
dynamically updated through a secured mechanism not to disrrupting on going
servics and communications.
The OpenVNET Local Daemon is used as an envelop encapsulating users\'
data and
service requests. It can delegate a group of combination of webservices,
service servers, and users.
3.1.4 OpenVNET Databank Info Server
The OpenVNET Databank Info Server is the information repository for the
OpenVNET server(s). It maintains information about OpenVNET client, server,
local daemon attributes in encoded token format, not private data. The
endcoding and decoding of tokens bewteen Webservice and OpenVNET Local Daemon
are localized only between two communicating parties. The user (or client) can
select his desired PKI crypto from a CryptoSuite from Local Daemon. The
encoding and decoding of tokens between OpenVNET Local Daemon and OpenVNET
Databank Info Server are made available through PKI. Trusted certificates are
only issued by OpenVNET root CA to OpenVNET Local Daemon, and clients get
certificates from its delegating OpenVNET Local Daemon.
OpenVNET Databank Info Server provides redundency at 1:1 or 4+1. (more
on this later)
A directory-enabled implementation of token repository may store client
token attributes in an secured LDAP directory infrastructure upon the client\'s
request OpenVNET Local Daemon. A token attribute will be designated for this
purpose.
3.1.5 .VNET Service Server
Any services that a client wants to provide. Token attributes are
allocated for this purpose. After the registration process is complete with
client\'s delegating OpenVNET Local Daemon. Service Server is visible on the
network through OpenVNET Local Daemon.
3.1.6 .VNET Management station
A .VNET Management station is a special type of OpenVNET .VNET client that
has access to all tokens stored in the OpenVNET Databank Info Server. It is
managed by OpenVNET .VNET Root Administrator. It is centralized in nature. It
provides root CA.
3.1.7 .VNETP
.VNETP is an encapsulation of OpenVNET Token System and RLS to interconnect
over OpenVNET.
3.1.8 .VNETCP
.VNETCP is a gateway-to-gateway channel protocol designed to interconnect
existing servers and network using TCP/IP. VNETCP maps the existing
identification into OpenVNET Token System.
3.2 OpenVNET Functional Components
Main functional components of the OpenVNET are listed below:
1) A Name Service Providing Peer (OpenVNET Local Daemon) Discovery
2) Discovery Domain (DD) and Login Control Service (Auth)
3) State Change Notification Service
4) CDSA security infrastructure
5) Secured Databank Info Service
3.2.1 Name Registration Service
The OpenVNET provides a registration function to allow all entities in a
network to register and query the directory. Both targets
and initiators can register in the OpenVNET, as well as query for
information about other initiators and targets. This allows, for
example, a client initiator to obtain information about target
services from the OpenVNET Local Daemon. This service is modeled in the
OpenVNET Local Daemon Name Server.
In order to maintain consistency between DNS Name-to-IP address
mappings stored in the OpenVNET Local Daemon, and the same mappings which
may exist in DNS servers, a common backend database storing such mappings may
be implemented to support both DNS and OpenVNET Local Daemon Naming Service
which in general will be token based. This backend database
can be based upon a standard network directory service such as LDAP on
OpenVNET Local Daemon in consistent with the ones in OpenVNET Databank Info
Servers.
The naming registration service also provides the ability to obtain
a network unique Domain ID (token) for OpenVNET Local Daemons when required.
3.2.2 Discovery Domain and Login Control Service
The Discovery Domain (DD) Service facilitates the partitioning of
OpenVNET client services into more manageable groupings for
administrative and login control purposes. This allows the
administrator to limit the login process to the more appropriate
subset of targets registered in the OpenVNET. This is the delegation process
between the OpenVNET Local Daemon and clients. OpenVNET clients must be in
at least one common DD in order to obtain information about each
other throuhg OpenVNET Local Daemon. OpenVNET clients can be a member of
multiple DD\'s simultaneously.
The DD information stored in the OpenVNET Local Daemon can be used by various
enforcement points in the network to configure security and access
control policy, only if the client sets the permission attributes of
multicasting. For example, a DD-aware OpenVNET Local Daemon can block service
initiators from accessing targets that are not in the same DD, even
if the initiator somehow obtained token information for a target
outside of its DD. This functionality is the equivalent of the
zoning functionality.
(...I put down this just as my thoughts. Barry might have more to say
about this)
Login Control allows targets to subordinate their access control
policy to the OpenVNET Local Daemon. The authorized target node
(registered) or service downloads the list of authorized initiator nodes in
token format from the OpenVNET .VNET network. Each node is uniquely
identified by an TOKEN with attributes. Only initiator nodes that match the
required identification and authenticating information provided by the OpenVNET
.VNET will be allowed access by that target node during session establishment.
If spoofing of initiator identities is a concern, the target may use the public
key certificate of the authorized initiator, obtained from its delegating
OpenVNET Local Daemon, to authenticate the initiator.
DD\'s can be managed offline by a separate management workstation, through
the OpenVNET .VETP or through .VNET DSNMP. If the target opts to use the Login
Control feature of the OpenVNET Local Daemon, the target subordinates
management of access control policy (i.e., the list of initiators (tokens)
allowed to login to that target) to the .VNET management workstations that are
manipulating information in the OpenVNET Local Daemon database.
If administratively authorized (by OpenVNET root Admin or ?) , a target can
upload its own Login Control list to the OpenVNET Databank Info Server. This
is accomplished using the DDReg message and listing the TOKEN of each initiator
to be registered in the Target\'s DD.
Depending on the implementation, newly registered nodes that have not
explicitly been placed into a DD by the management station MAY be placed into a
\"default DD\" where they are visible to other OpenVNET Local Daemons in that
DD. Other implementations MAY decide that they are registered with no DD,
making them inaccessible to source-scoped
OpenVNETP messages.
The SOURCE field of every OpenVNET query and registration message is used to
determine the source of the request and scope the operation to the set of
Discovery Domains on the OpenVNET Local Daemon that the OpenVNET client is a
member of.
If the SOURCE field contains NULL, the OpenVNET query and registration
message SHALL BE scoped to the entire contents of the OpenVNET, regardless of
the configuration of Discovery Domains.
Enabled Discovery Domains (DD\'s) belong to at least one active Discovery
Domain Sets (DDS\'s). Discovery Domains that do not belong to an activated DDS
are not enabled.
3.2.3 State Change Notification Service
The State Change Notification (SCN) service allows the OpenVNET Local Daemon
to issue notifications about network .VNETs that affect the operational state
of OpenVNET clients. The OpenVNET client and service server has the ability to
register for these notifications of .VNETs detected by the OpenVNET .VNET. The
types of .VNETs for which SCNs can be sent include change in Discovery Domain
(DD) membership and service registration updates.
The State Change Notification service utilizes the Discovery Domain Service
to control the distribution of notification messages. Notifications about
changes within a DD are limited to members of that DD, and is only controlled
by the OpenVNET Local Daemon.
If any of OpenVNET Local Daemons is unable to service an SCN registration it
SHALL reject the SCN registration request, returning a SCN Registration
Rejected error code. The rejection might occur in situations where the
network size, current level of SCN registrations, or current service
condition has passed an implementation-specific threshold or some critical
sessions in progress. A client not allowed to register for SCNs SHOULD monitor
its sessions with other OpenVNET Local Daemons directly.
The specific notification mechanism by which the OpenVNET learns of the
.VNETs is implementation-specific, but can include examples such as explicit
notification messages from an OpenVNET client to the OpenVNET Local Daemon, or
an interruption of servie by the OpenVNET Local Daemon to a detected possible
intrusion of access as a result.
3.2.4 CDSA security infrastructure (TBS)
3.2.5 Secured Databank Info Service (TBS, Barry -- may be ?)
3.3 OpenVNET and Domain Name System (DNS)
A directory-enabled OpenVNET implementation may use LDAP to store OpenVNET
client token attributes. If this is the case, then LDAP can be used to support
both the OpenVNET .VNET and DNS server infrastructures, maintaining consistency
in Domain Name-to-IP address mappings used by DNS and OpenVNET .VNET token
system (Virtual identity).
3.4 OpenVNET .VNET and LDAP
LDAP is a passive service designed to deliver scalable directory services
using a get/set model. Applications designed and tailored to specific user
requirements interact with LDAP on the OpenVNET Local Daemon for their generic
directory service needs. On the other hand, OpenVNET .VNET Local Daemon is an
application that goes beyond the simple get/set model, and provides specific
capabilities needed to monitor and manage an enterprise-scale network.
OpenVNET Local Daemon is one example of an application that can leverage the
services of LDAP. By layering OpenVNET .VNET on top of LDAP, the capabilities
of both OpenVNET .VNET and LDAP can be leveraged to manage and scale the
enterprise IP network.
The OpenVNET .VNET Local Daemon application provides capabilities that LDAP
alone is not designed to achieve. This includes the following:
1) Client Attribute Awareness - The OpenVNET Local Daemon application
interprets attribute values submitted by clients in registration messages, and
can take appropriate action based upon specific registered attribute values.
The OpenVNET Local Daemon is conscious of the state of each client.
2) State Change Notification - An OpenVNET Local Daemon may initiate
notification messages to clients in the .VNET of a change in the network, such
as the non-availability or reachability of a OpenVNET Local Daemon, or a
specific change in the value of a client or service server attribute.
3) Monitoring of Clients - OpenVNET Local Daemon provides a Entity Status
Inquiry message to verify the availability and reachability of end-points.
4) Lightweight - OpenVNETP is a simple and lightweight protocol suitable
for implementation on OpenVNET Local Daemon such as softswitches (or gateway)
delegating a group of clients and service servers, or resides with the client
as a single component.
3.5 OpenVNET Server Discovery
The Service Location Protocol (SLP) provides a flexible and scalable
framework for providing nodes with access to information about the existence,
location, and configuration of networked services, including the service
servers under a particaular OpenVNET Local Daemon. SLP MAY be used by OpenVNET
clients to discover the IP address of the OpenVNET Local Daemon or a service
server on OpenVNET .VNET. To implement discovery through SLP, a Service Agent
(SA) should be cohosted in the OpenVNET Local Daemon, and a User Agent (UA)
should be in each OpenVNET client. Each client requests a multicasting
discovery message through OpenVNET Local Daemon to request the IP address of
the OpenVNET serice server(s) and OpenVNET Local Daemons. The SA responds to
this request if any of the OpenVNET service servers and OpenVNET Local Daemons
have the permission attributes authorized to provide such. Optionally, the
location of the OpenVNET nods can be stored in the SLP Directory Agent (DA) on
the delegating OpenVNET Local Daemon.
Note that a complete description and specification of SLP can be
found in [RFC2608], and is beyond the scope of this document.
If SLP is not used, then the IP address of the OpenVNET Local Daemon can be
stored in a DHCP server to be downloaded using a DHCP option, such as any of
the reserved site-specific option codes (from 128 to 255). Another approach is
to configure each OpenVNET client to listen to the OpenVNET Name Service
Heartbeat message (see section 7.6.5.14). A final approach would be to
manually configure the IP address of the OpenVNET Local Daemon. This feature
will support LAN/WAN, ISP, or enterprise environment.
3.6 OpenVNET and NAT
The existence of NAT will have an impact upon information retrieved from the
OpenVNET Local Daemon. If the OpenVNET client or service server exists in a
different addressing domain than the OpenVNET Local Daemon, then IP address
information stored in the OpenVNET Local Daemon may not be correct when
interpreted in the domain of the OpenVNET client.
There are several possible approaches to allow operation of OpenVNET within
a NAT network. The first approach is to require use of the canonical TCP port
number by both targets and initiators when addressing targets across a NAT
boundary, and for the OpenVNET client to not query for nominal IP addresses.
Rather, an OpenVNET client initiator SHALL send query to OpenVNET Local Daemon
for the DNS Fully Qualified Domain Name (i.e., Entity Identifier) when seeking
addressing information. Once retrieved, the DNS name can be interpreted in
each address domain and mapped to the appropriate IP address by local DNS
servers, and then mapped to OpenVNET Token System.
A second approach is to deploy a distributed network of OpenVNET Local
Daemons. OpenVNET Local Daemons are deployed inside and outside NAT boundaries,
with each one storing relevant IP addresses for their respective NAT domains.
Updates among the network of decentralized, local OpenVNET Local Daemon are
handled using LDAP and using appropriate NAT translation rules implemented
within the update mechanism in each OpenVNET Local Daemon.
A final approach is to simply disallow use of NAT in between communication
between the OpenVNET Local Daemon and any OpenVNET client. However, two proxy
components are needed, one on OpenVNET Local Daemon, one on client in front of
webservice.
3.7 Interactions Between .VNET Local Daemon Infrastructures
Each individual .VNET Local Daemon deployment is designed to be operated in
networks under the control of a single administrative authority. This
administrative authority facilitates a seamless, integrated policy for .VNET
usage, including security, naming and registration of storage assets,
and management of Discovery Domains. Through leverage of an Internet-based
database framework such as LDAP, the .VNET not only scales to large
networks, but also to support interactions among multiple independently
managed .VNET infrastructures, each managed by its own administrative
authority.
The information registered in the .VNET Local Daemon can be shared with
other .VNET Local Daemon managed by other administrative authorities through
out-of-band, non-.VNET protocols. By importing registration information
from a remote .VNET Local Daemon, connectivity can be established to nodes
managed by that .VNET Local Daemon.
The following examples illustrate possible methods to transfer .VNET data
records of node between autonomous, independently-administered .VNET Local
Daemons. In the first example, a back-end LDAP information base is used to
support the .VNET Local Daemon. The following diagram illustrates use of
the LDAP protocol to import .VNET Local Daemon registration information from
one .VNET Local Daemon to another. Once the record transfer of the remote
service is completed, it becomes visible and accessible to delegated clients
and service servers. This allows local nodes to establish sessions with
remote .VNET Local Daemon (client/Server but only through .VNET Local
Daemon) (provided firewall boundaries can be negotiated).
+-------------------------+ +-------------------------+
|+------+ .VNETP | | .VNETP +-----+ |
||xxx A |<----->+------+ | | +------+<----->|xxx C| |
|+------+ | | | | | | +-----+ |
|+------+ |.VNET | | | | .VNET | +-----+ |
||xxx B |<---->|Local | | | | Local |<---->|yyy D| |
|+------+ |Daemon | | | | Daemon| +-----+ |
|........ +--+---+| | WAN | +---+--+ |
|.xxx C\'. | | Link | | |
|........ | ============= | |
| | | | | |
| +--+---+ | | +---+--+ |
| | local|<--- <--- <--- <--|remote| |
| | LDAP | | LDAP: | | LDAP | |
| +------+ | \"xxx C\" | +------+ |
+-------------------------+ Xfer +-------------------------+
Network A Network B
In the above diagram, two partners wish to share services
\"xxx C\". Using LDAP, the record for \"xxx C\" service can be transfered
from Network B to Network A. Once accessible to the .VNET Local
Daemon in Network A, local xxx A and xxx B can now discover and
connect to \"xxx C\". \"xxx C\" becomes a Virtual Identity of xxx C\' service
ont .VNET.
+-------------------------+ +-------------------------+
|+------+ .VNETP | | .VNETP +-----+ |
||xxx A |<----->+------+ | | +------+<----->|xxx C| |
|+------+ | | | | |remote| +-----+ |
|+------+ |.VNET | | | |.VNET | +-----+ |
||xxx B |<----->| Local| | | |Local |<----->|xxx D| |
|+------+ |Daemon| | | |Daemon| +-----+ |
|........ +------+ | WAN | +---+--+ |
|.xxx C\'. ^ | | Link | | | |
|........ | | |<=======>| v v |
| | | | | DNMP |
| | v | | | |
| +--+--+ | | v |
| | DNMP | <--- <--- <--- <---- |
| | Mgmt | | DNMP: Xfer \"xxx C\" |
| |Station| | | |
| +-------+ | | |
+-------------------------+ +-------------------------+
Network A Network B
The above diagram illustrates a second example of how .VNET records
can be shared. In this case, the .VNET Local Daemon are not using LDAP to
store records. This method uses an DNMP-based management station in
.VNET Local Daemon to download the desired record for \"xxx C\", and then
directly upload it to the requesting .VNET Local Daemon. Once the record is
transfered to the .VNET Local Daemon in Network A, \"xxx C\" becomes visible
and accessible.
(provided firewall boundaries can be negotiated) to other nodes in
Network A.
Other methods, including proprietary protocols, can be used to
transfer service records between independently-administered .VNET
Local Daemons by using .VNETCP with .VNET Gateway-to-Gateway protocol.
3.8 Deployment Architecture Diagram
The following diagram displays examples of where and how .VNET
components can be deployed.
+--------------+ +-----------+ +--------------+
| DNS Server | LDAP | .VNET | LDAP | .VNET |
| or .VNET |<------>| Databank |<------>| .VNET |
|Naming Service| | Info | | Local Deamons|
+------+-------+ +-----+-----+ +-------+------+
| | |
| DNS | LDAP .VNETP |
|Queries |(or else) |
+------+----------------------+----------------------+---------+
| |
| .VNET |
| |
+----+-----------+----------+---------------+------------------+
^ | | |
| | | +-----+-----+
| | | |.VNET |
| | | | |
| | | |Gtwy/Server|
| | | +-----+-----+
v | | | .VNETCP
+----+----+ +----+------+ +---+-----+ +----+-+ +---+----+
|(client) | | requested | |.VNET | | other Network |
|Initiator| | node | |Local | |or .other VNET |
+---------+ +-----------+ |Daemon | | Network |
+---------+ +-----------------+
4. .VNET Object Model
.VNET provides the framework for the registration and discovery of
.VNET nodes and other foreign nodes. This architecture defines common
objects that can be used to represent components referenced by each of these
nodes.
This architecture framework provides elements needed to describe various
.VNET node objects and attributes that may exist on an .VNET network.
Objects defined in this architecture framework include DATABANK INFO SERVER,
NETWORK ENTITY, .VNET LOCAL DAEMON, TOKEN, WEBSERVICE, .VNET CLIENT, VIRTUAL
IDENTITY, DISCOVERY DOMAIN, and DISCOVERY DOMAIN SET. Each of these objects
are described in greater detail in the following sections.
1. NETWORK ENTITY includes DATABANK INFO SERVER, .VNET LOCAL DAEMON,
DISCOVERY DOMAIN, DISCOVERY DOMAIN SET, CDSA, TOKEN, DIRECTORY,
and NODE.
2. NODE includes .VNET CLIENT, SERVICE SERVER, WEBSERVICE, and .VNET
LOCAL
DAEMON.
3. TOKEN includes .VNET Token System.
4. VIRTUAL IDENTIY is an identification used in .VNETP and .VNETCP.
4.1 NETWORK ENTITY Object
The NETWORK ENTITY object is a container of TOKEN objects, .VNET LOCAL
DAEMON, and DATABANK INFO SERVER objects. It represents a set of .VNET LOCAL
MON or gateway that is accessible from/to the .VNET network. All
NODEs and .VNET LOCAL DAEMONs contained in a NETWORK ENTITY object operate in
a coordinated manner.
4.2 .VNET LOCAL DAEMON Object
The .VNET LOCAL DAEMON object is an IP interface through which access to any
NODE within the NETWORK ENTITY can be obtained. A NETWORK ENTITY must have
one or more .VNET LOCAL DAEMONs, each of which is usable by NODEs contained
in that NETWORK ENTITY to gain access to, or be accessible from, the IP
network.
4.3 DIRECTORY Object
The DIRECTORY object is the logical endpoint of an .VNET LOCAL DAEMON
connection session. The session endpoint is represented by TOKEN.
TOKEN defines tokens with attributes for NETWORK ENTIY.
4.4 NODE Object
The NODE Object represents .VNET CLIENT, WEBSERVICE, SERVICE SERVER end
nodes. All NODE Objects have a set of tokens and attributes defined. These
defined tokens and attributes are used in combination with TOKEN to establish
a VIRTUAL IDENTIY for each NODE Object and NODE Object request.
4.5 DISCOVERY DOMAIN Object
DISCOVERY DOMAINS (DD) are a security and management mechanism used to
partition NETWORK ENTITY resources. Discovery Domains limit the discovery
process to the administrator-configured subset of relevant NODE, .VNET LOCAL
DAEMON, and DATABANK INFO SERVER pr.VNETing initiators from inappropriately
attempting login to that they shouldn\'t have access to. When queried, the
.VNET LOCAL DAEMON will provide information only for network node entities
that share at least one common DD. Initiators will not be able to \"see\"
nodes with which they do not have at least one common DD.
4.6 DISCOVERY DOMAIN SET Object
The DISCOVERY DOMAIN SET (DDS) is a container object for DD\'s. DDS\'s may
contain one or more DD\'s. Similarly, each DD can be a member of one or more
DDS\'s. DDS\'s are a mechanism to store coordinated sets of DD mappings in
the
NETWORK ENTITY.
4.7 OpenVNET Database Model
The following shows the the various objects described above and
their relationship to each other.
+--------------+ +-----------------------+
| NETWORK |1 *| |
| ENTITY |----| .VNET LOCAL DAEMON |
| | | |
+--------------+ +-----------------------+
| 1
|
|
| *
+-----------+ +--------------+ +-----------+ +-----------+
| |1 *| .VNET |* *| DISCOVERY |* *| DISCOVERY |
| NODE |----| LOCAL |----| DOMAIN |----| DOMAIN |
| | | DAEMON | | | | SET |
+-----------+ +--------------+ +-----------+ +-----------+
* represents 0 to many possible relationships
5. OpenVNET Implementation Requirements
OpenVNET can be implemented with features to support native OpenVNET .VNETWP,
.VNETP, and .VNETCP, and not native protocols. Implementation of support for
either or both of these protocols is OPTIONAL. IF OpenVNET .VNET is
implemented
to support a particular protocol, then a minimum set of attributes and
.VNETWP, .VNETP, and .VNETCP commands is REQUIRED for support of that
protocol. This section details specific requirements for support of each of
these protocols.
5.1 OpenVNET .VNET Local Daemon Requirements
In OpenVNET .VNET Local Daemon, use of OpenVNET is REQUIRED. No alternatives
exist for support of OpenVNET .VNET Local Daemon Naming & Discovery
functions.
In addition, OpenVNET .VNET Local Daemon Gateway is integral to the operation
of OpenVNET .VNET Local Daemon, in order to allow OpenVNET .VNET Local Daemon
gateways to interface to OpenVNET .VNET. Mappings to OpenVNET Token System is
rquired.
5.1.1 Required Attributes for Support of OpenVNET .VNET Local Daemon
The following table displays (or suggestes) attributes that are used by
OpenVNET .VNET to support OpenVNET .VNET Local Daemon. Attributes indicated
in
the REQUIRED TO IMPLEMENT column MUST be supported by the OpenVNET NETWORK
ENTITY and all NODE participants.
Attributes indicated in the REQUIRED TO USE column MUST be supported
by OpenVNET .VNET NETWORK ENTITY, NODE, and OpenVNET .VNET Local Daemon
Gateways.
REQUIRED REQUIRED
Object Attribute to
Implement to Use
------ ---------
------------ --------
NETWORK ENTITY Entity Identifier *
*
Entity Protocol *
*
Management IP Address
Timestamp *
Protocol Version Range *
Entity Certificate *
(not used if guests)
.VNET LOCAL DAEMON IP Address *
*
TCP/UDP Port
* *
.VNET LOCAL DAEMON Token
* *
.VNET LOCAL DAEMON Group *
.VNET LOCAL DAEMON Certificate *
NODE Port Name
* *
Port_ID
* *
Port Type
* *
Port Token
*
Class of Service
*
Service Types
*
Service Descriptors
*
Service Features
*
SCN Event Bitmap
*
Node Certificate
*
DISCOVERY DOMAIN DD_ID
* *
DD_Token
*
DISCOVERY DOMAIN DDS Identifier
*
SET DDS Token
*
Status
*
5.1.2 Attribute Descriptions for OpenVNET .VNET Local Daemon
The OpenVNET attributes used to support OpenVNET .VNET Local Daemon are
shown and
described in the following figure: (All attributes described below will be
encapsulated by .VNET Token)
- OpenVNET .VNET Service Server-Specific
- Preferred_ID
- Assigned_ID
- Space_Identifier
- Assigned OpenVNET .VNET Token
- OpenVNET .VNET Local Daemon NETWORK ENTITY
|
- Entity Identifier
| By convention this is the DNS name of the
| .VNET LOCAL DAEMON IP-Address(es) mapped to .VNET Token. If it is not
registered
| the OpenVNET will assign a unique alphanumeric identifier to it.
- Entity Protocol
| Indicates this is an OpenVNET .VNET Local Daemon registration
- Management IP-Address
| If it is not registered then in-band management
| is assumed.
- Timestamp
| Last registration update. Maintained by the OpenVNET.
- Protocol Version Range
| Indicates the OpenVNET .VNET Local Daemon versions supported
- Entity Certificate
| X.509 certificate bound to the Entity (FQDN)
|
- .VNET LOCAL DAEMON (1 - n per ENTITY)
| |
| - IP-Address
| - TCP/UDP Port
| | The IP-Address and Port combined uniquely
| | define a .VNET LOCAL DAEMON and then mapped to .VNET Token.
| - .VNET LOCAL DAEMON Token
| - Entity Status Inquiry Interval
| | 0 if no status inquiry is used
| - Entity Status Inquiry Port
| | The port used to receive ESIs
| - .VNET LOCAL DAEMON Group
| | The aggregation group this .VNET LOCAL DAEMON is a member of
| - .VNET LOCAL DAEMON Certificate (.VNET delegation)
|
- NODE (1 - k per ENTITY)
|
- Port
- Port ID
- Port Type
- Port Token
- Class of Service
- Srevice Types
- Service Descriptors
- Service Features
- SCN Bitmap
- Node Certificate
5.1.3 OpenVNET .VNET Local Daemon Gateway Attribute Requirements
5.1.3.1 Port_ID_Token
Port_ID_Token assignments for each NODE object within a single NETWORK ENTITY
SHALL be unique. For each NETWORK ENTITY (i.e., OpenVNET .VNET Local Daemon
Gateway), no more than one NODE can be assigned a given PORT_ID_Token value.
5.1.4 Example OpenVNET .VNET Local Daemon Object Model Diagram
The OpenVNET .VNET Local Daemon protocol allows native OpenVNET .VNET NODE
Object
to an OpenVNET .VNET Local Daemon , to be directly internetworked using IP.
When supporting OpenVNET .VNET NODEs, the OpenVNET .VNET Local Daemon stores
NODE
Object attributes, OpenVNET .VNET Local Daemon gateway attributes, and
OpenVNET
.VNET Databank Info Server attributes that might also be stored in an .VNET
name server.
The following diagram shows a representation of a OpenVNET Local Daemon
supporting multiple NODE Objects behind it. The two .VNET LOCAL DAEMON
objects represent IP interfaces on the OpenVNET .VNET Local Daemon that can
be
used to access any of the three NODE objects behind it. Note that the NODE
object is not contained in the NETWORK ENTITY object.
However, each NODE Object has a relationship to one or more NODE objects.
(TBS)
(Port ID = Port ID Token, COS - Service Tokens)
5.1.5 Required Commands and Response Messages for Support of OpenVNET .VNET
Local Daemon
The .VNETP messages and responses displayed in the following tables are also
available to support OpenVNET .VNET Local Daemon gateways. Messages
indicated
in the REQUIRED TO IMPLEMENT column MUST be supported by the OpenVNET NODE.
Messages indicated in the REQUIRED TO USE column MUST be supported by the
OpenVNET .VNET Local Daemon themselves.
REQUIRED TO:
Message Description Abbreviation Func ID Implement
Use
------------------- ------------ ------- ---------
---
Register Attr Req RegDevAttr 0x0001 *
*
Attr Query Request DevAttrQry 0x0002 *
*
Get Next Request DevGetNext 0x0003 *
Deregister Dev Request DeregDev 0x0004 *
*
SCN Register Request SCNReg 0x0005 *
SCN Deregister Request SCNDereg 0x0006 *
SCN Event SCNEvent 0x0007 *
State Change Notification SCN 0x0008 *
DD Register DDReg 0x0009 *
*
DD Deregister DDDereg 0x000A
* *
DDS Register DDSReg 0x000B *
*
DDS Deregister DDSDereg 0x000C *
*
Name Service Heartbeat Heartbeat 0x000E *
Reserved Reserved 0x000F-0x0010
Request Gateway ID RqstGwId 0x0011
Release Gateway ID RlseGwId 0x0012
Get Gateway IDs GetGwIds 0x0013
RESERVED 0x0014-0x00FF
Vendor Specific 0x0100-0x01FF
RESERVED 0x0200-0x8000
The following are .VNETP response messages in support of OpenVNET .VNET Local
Daemon:
REQUIRED TO:
Response Message Desc Abbreviation Func_ID
Implement Use
--------------------- ------------ -------
--------- ---
Register Attr Rsp RegDevRsp 0x8001 *
*
Attr Query Resp DevAttrQryRsp 0x8002 *
*
Get Next Resp DevGetNextRsp 0x8003 *
Deregister Dev Resp DeregDevRsp 0x8004 *
*
SCN Register Resp SCNRegRsp 0x8005 *
SCN Deregister Resp SCNDeregRsp 0x8006 *
SCN Event Resp SCNEventRsp 0x8007 *
SCN Response SCNRsp 0x8008 *
DD Register Rsp DDRegRsp 0x8009 *
*
DD Deregister Rsp DDDeregRsp 0x800A *
*
DDS Register Rsp DDSRegRsp 0x800B *
*
DDS Deregister Rsp DDSDeregRsp 0x800C *
*
NOT USED 0x800E
RESERVED 0x800F-0x8010
Request Gateway ID Resp RqstGwIdRsp 0x8011
Release Gateway ID Resp RlseGwIdRsp 0x8012
Get Gateway IDs GetGwIdRsp 0x0013
RESERVED 0x8014-0x80FF
Vendor Specific 0x8100-0x81FF
RESERVED 0x8200-0xFFFF
5.2 NODE Requirements
5.3 Attribute Descriptions for Discovery Domain Registration
Discovery Domains are logical groupings of initiators and targets
that are used to limit the login process to the appropriate subset
of services registered in the OpenVNET.
Support for Discovery Domains is required for all protocols. The
OpenVNET attributes for Discovery Domain, and Discovery Domain Set,
registration are shown in the following figure:
DISCOVERY DOMAIN SET
|
- DD Set_ID
- DD Set_Symbolic Name
- DD Set Enabled/Disabled
DD SET_MEMBER
|
- DD Set_ID
- DD_ID
DISCOVERY DOMAIN
|
- DD_ID
- DD_Symbolic Name
DD_MEMBER
|
- DD_ID
- Entity Identifier, .VNET Name, or WWPN
Members of a Discovery Domain can be defined by registering one of
the following storage entity attributes in a Discovery Domain:
- .VNET Name : this places the individual .VNET
storage node in the Discovery Domain
- WWPN : this places the Virtual Channel Node in the
Discovery Domain
5.4 Use of TCP For OpenVNET .VNET Communication
TCP can be used for all OpenVNET communication. The OpenVNET server SHALL
accept TCP connections for client registrations. The TCP port used
by the OpenVNET server to receive TCP messages used SHALL be <<TBD>>.
The client can also use multiple streams to register attributes and
communicate with the server.
To register for ESI monitoring using TCP, the client SHALL register
the .VNET LOCAL DAEMON ESI Interval using the TCP connection that will be
used to receive ESI inquiry messages.
To register for SCN notifications using TCP, the client SHALL
register the .VNET/Virtual Channel SCN Bitmap using the TCP connection that
SHALL be used to receive SCN notification messages.
This allows the client to be flexible about how many and which
connections will be used for each feature. Using the above method,
a client can optionally open one stream and use it for SCN, ESI, and
OpenVNET queries. A client may also open up 3 sessions: one for ESI,
one for SCN, and another for OpenVNET queries.
If a TCP connection supporting ESI or SCN messages goes down, and
the client creates a new connection for the ESI or SCN messages,
then the client must reregister for ESI\'s and/or SCN\'s on the new
connection.
5.5 Use of UDP For OpenVNET .VNET Communication
The OpenVNET server MAY accept UDP messages for client registrations.
The OpenVNET server SHALL accept registrations from clients requesting
UDP-based ESI and SCN messages. The UDP port used to receive
messages SHALL be <<TBD>>.
To register for UDP-based ESI monitoring messages, the client SHALL
register the .VNET LOCAL DAEMON ESI/SCN UDP Port to be used for communication
of ESI messages from the server to the client.
To register for UDP-based SCN notifications messages, the client
SHALL register at least one .VNET LOCAL DAEMON ESI/SCN UDP port to be used
for communication of SCN messages from the server to the client. If an
entity has multiple .VNET LOCAL DAEMONs with registered ESI/SCN UDP Ports,
then ESI and SCN messages SHALL be delivered to each .VNET LOCAL DAEMON
registered to receive such messages.
6. OpenVNET .VNET Message Attributes
When an OpenVNET client registers with the OpenVNET server, it provides
attribute values to describe the entity characteristics and
capabilities. The OpenVNET server also returns the attributes in
response to queries.
6.1 OpenVNET .VNET Attribute Summary
The following table lists all .VNETP message attributes for service
registration and queries:
(TBS)
The following is a description of the columns used in the above
table:
(TBS)
A well-formed registration contains the key of the object to
register, or no key if it can be generated by the OpenVNET. If an
attribute is present as a key, then it cannot be an operating
attribute.
The registration response will contain the key for each object
registered, including any key values that were assigned by the OpenVNET
as part of the registration. For example, if an entity, two
.VNET LOCAL DAEMONs, and one Virtual Channel node was registered, then the
response message key attributes section would contain the keys for each. The
key attributes, returned in the response, may be in a different order
they appeared in the registration.
OpenVNET client attributes are defined below.
6.2 Virtual Entity Identifier-Token Keyed Attributes
The following attributes are registered in the OpenVNET using the Entity
Identifier attribute as the key.
6.2.1 Virtual Entity Identifier (VEID)
The Entity Identifier is a variable length identifier that uniquely
identifies each network entity registered in the OpenVNET. The
attribute length varies from 4 to 256 bytes, and is a unique value
within the OpenVNET.
If the OpenVNET client does not provide an EID during registration the
OpenVNET shall generate one that is unique within the OpenVNET. If an EID
is to be generated, then the EID attribute value in the registration
message shall be empty (0 length). The generated EID shall be
returned in the registration response.
By convention, OpenVNET generated EIDs begin with the string OpenVNET:???
(where ??? might be a SHA-1 hashed OID + RLS + WWNP or WWNN).
If an EID is registered by a client beginning with the string
OpenVNET:??? then the OpenVNET server SHALL not assign the value to another
entity.
6.2.2 Virtual Entity Protocol
Entity Protocol is a required 4-byte attribute that indicates the
protocol of network entity that is being registered and is provided
by the OpenVNET client. The valid types are defined as below:
(TBS)
6.2.3 Management IP Address
This optional field is provided by the OpenVNET client. It contains the
IP Address used to manage the entity. The Management IP Address is
a 16-byte field that may contain either a 32-bit IPv4 or 128-bit
IPv6 address. When this field contains an IPv4 value, the most
significant 12 bytes are set to 0x00. If the network entity is
capable of being managed and this field is not set, then in-band
management is assumed.
6.2.4 Entity Registration Timestamp
This field is updated by the OpenVNET. It cannot be used as a query key
or be explicitly registered. It indicates the time the entity
registration occurred, an associated object was updated, or the time
of the most recent response to an Entity Status Inquiry message,
whichever is later. The time format is, in seconds, the update
period since the standard base time of 00:00:00 GMT on January 1,
1970.
6.2.5 Protocol Version Range
This optional field is provided by the OpenVNET client. This field
contains the minimum and maximum version of the protocol supported
by the entity. The most significant two bytes contain the maximum
version supported, and the least significant two bytes contain the
minimum version supported. If a range is not registered then the
entity is assumed to support all versions of the protocol.
6.2.6 Registration Period
This required field, provided by the OpenVNET client, indicates the
maximum period, in seconds, that the entity registration will be
maintained by the server without an update or ESI response from the
client. If the Registration Period is set to 0, then the Entity
SHALL NOT be deregistered as a result of no update messages from the
client.
To refresh the registration, the OpenVNET client may perform a re-
registration with the update flag set, which updates any field of
the registration.
Byte 0 and 1 represents the entity registration period, in seconds.
Byte 2 and 3 are reserved.
If ESI support is requested as part of a .VNET LOCAL DAEMON registration, the
ESI Response message received by the server SHALL act as an
alternative to an update of the entity registration.
If ESI messages are not requested by an entity and the Registration
Period is not set to 0, then the entity registration SHALL be
removed if the client does not update the registration before the
registration period has expired.
6.2.7 Entity Certificate
This attribute contains an X.509 certificate that is bound to the
NETWORK ENTITY of the OpenVNET client. This certificate is uploaded and
registered to the OpenVNET by clients wishing to allow other clients to
authenticate themselves and access the services offered by that
NETWORK ENTITY. This certificate MAY also be used to set up the TLS
association between the OpenVNET client and server, as well as to key
the authentication block in the .VNETP. The maximum size of this
variable length field is implementation dependent.
6.3 .VNET LOCAL DAEMON-Token Keyed Attributes
The following .VNET LOCAL DAEMON attributes are registered in the OpenVNET
using the combined .VNET LOCAL DAEMON IP-Address and .VNET LOCAL DAEMON
TCP/UDP Port as the key. Each .VNET LOCAL DAEMON is associated with one
Entity Identifier object key.
6.3.1 .VNET LOCAL DAEMON IP-Address
The IP address of the .VNET LOCAL DAEMON through which a NODE can
transmit and receive storage data. This required field is provided
by the OpenVNET client. When an IPv4 value is contained in this field,
the most significant 12 bytes are set to 0x00. The .VNET LOCAL DAEMON IP
Address along with the .VNET LOCAL DAEMON TCP/UDP Port number uniquely
identifies a .VNET LOCAL DAEMON.
6.3.2 .VNET LOCAL DAEMON TCP/UDP Port
The TCP/UDP port of the .VNET LOCAL DAEMON through which a NODE can
transmit and receive storage data. This required 4 byte field is
provided by the OpenVNET client. Bit 0 to 15 represents the TCP/UDP
port number. Bit 16 represents the port type. If bit 16 is set the
port type is UDP. Otherwise it is TCP. Bits 17 to 31 are reserved.
If the field value is 0, then the port number is the implied
canonical port number and type of the protocol indicated by the
associated Entity Protocol.
The .VNET LOCAL DAEMON IP-Address along with the .VNET LOCAL DAEMON TCP/UDP
Port number uniquely identifies a .VNET LOCAL DAEMON.
6.3.3 .VNET LOCAL DAEMON Token
This is an optional, variable-length text-based value from 0 to 256
bytes. The text field contains user-readable UTF-8 text, and is
terminated with at least one NULL character. The .VNET LOCAL DAEMON Symbolic
Name is a user-readable description of the .VNET LOCAL DAEMON entry in the
OpenVNET.
6.3.4 Entity Status Inquiry Interval
This optional field is provided by the OpenVNET client. It indicates
the minimum time, in seconds, between Entity Status Inquiry (ESI)
messages sent from the OpenVNET to this entity .VNET LOCAL DAEMON. ESI
messages can be used to verify that a .VNET LOCAL DAEMON registration
continues to be valid.
To request monitoring by the OpenVNET, an OpenVNET client registers a non-
zero value for this .VNET LOCAL DAEMON attribute using a RegDevAttr message.
If the OpenVNET does not receive an ESI response message from a .VNET LOCAL
DAEMON after having sent no more than three ESI messages, then the .VNET
LOCAL DAEMON SHALL be deregistered.
If all .VNET LOCAL DAEMONs associated with an entity that have registered for
ESI messages are deregistered due to non-response, then the entity
SHALL be deregistered.
If the OpenVNET is unable to support ESI messages, it SHALL reject the
ESI request by returning an \"ESI Not Available\" error code. The
rejection might occur in situations where the resulting frequency of
ESI messages being issued to clients would pass an implementation-
specific threshold.
6.3.5 ESI/SCN UDP Port
This optional field is provided by the OpenVNET client. If the client
requires UDP based ESI monitoring or SCN notification, it SHALL
register the UDP port to be used for communication from the server
to a client .VNET LOCAL DAEMON. Bit 0 to 15 represents the UDP port number.
Bits 16 to 31 are reserved.
If an entity node registers for SCN notifications with a UDP
message, at least one entity .VNET LOCAL DAEMON shall have a registered
ESI/SCN UDP port number. The OpenVNET server will return an error for an SCN
registration if no ESI/SCN port has been registered. If multiple
.VNET LOCAL DAEMONs have a registered ESI/SCN UDP port, then SCN data MAY be
delivered to any of the available registered .VNET LOCAL DAEMONs.
6.3.6 .VNET LOCAL DAEMON Delegating Group
This optional field is provided by the OpenVNET client. The .VNET LOCAL
DAEMON
Group is used to group .VNET LOCAL DAEMONs into aggregation groups. All
entity .VNET LOCAL DAEMONs that belong to the same .VNET LOCAL DAEMON Group
can provide connections to the same NODE. This allows multiple sessions to
be established to a node through multiple .VNET LOCAL DAEMONs. The least
significant two bytes contain the .VNET LOCAL DAEMON Group for the .VNET
LOCAL DAEMON. The most significant two bytes are reserved.
6.3.7 .VNET LOCAL DAEMON Certificate
This attribute contains an X.509 certificate that is bound to the
.VNET LOCAL DAEMON of the OpenVNET client. This certificate is used to
identify and authenticate communications to the IP address supported by the
.VNET LOCAL DAEMON. This certificate MAY be used to set up the authenticating
SA supporting the authentication block for .VNETP messages originated
from the .VNET LOCAL DAEMON IP Address.
6.4 OpenVNET .VNET WEBSERVICE Object Node-Keyed Attributes
The following attributes are registered in the OpenVNET using the OpenVNET
.VNET
WEBSERVICE Object Node World Wide Port Name (WWPN) attribute as the key.
Each set of OpenVNET .VNET WEBSERVICE Object Node-Keyed attributes is
associated with one Entity Identifier object key.
Although the OpenVNET .VNET WEBSERVICE Object Node WWPN is associated with
one
Entity Identifier, it is globally unique.
6.4.1 OpenVNET .VNET WEBSERVICE Object Node Port Name
This 64-bit identifier uniquely defines the OpenVNET .VNET WEBSERVICE Object
Node, and is the World Wide Port Name (WWPN) of the corresponding Virtual
Channel service. This globally unique identifier is used during the service
registration process, and uses a value conforming to IEEE Naming
Assignment Authority (NAA) type 1, 2, 5, or 6. This format is found
in ANSI/IEEE Std 802-1990 [802-1990].
6.4.2 Port ID
Along with the IP Address, this field uniquely identifies a native
Virtual Channel service port in the network, and maps one-to-one to a
specific Port Name (WWPN) entry. The Port ID is used for OpenVNET .VNET
WEBSERVICE Object based storage services.
6.4.3 Port Type
Indicates the type of OpenVNET .VNET WEBSERVICE Object node port. This is
provided by the OpenVNET client. Encoded values for this field are listed in
the following table:
Type Description
---- -----------
0x0000 Unidentified/Null Entry
0x0004-0080 RESERVED
0x0083 RESERVED
0x0085-00FF RESERVED
0xFF12 OpenVNET .VNET WEBSERVICE Object Port
0xFF13-FFFF RESERVED
6.4.4 OpenVNET .VNET WEBSERVICE Object Node Port Token
A variable-length text-based description of up to 255 bytes, that is
associated with the OpenVNET-registered OpenVNET .VNET WEBSERVICE Object
Node in
the network. The text field contains user-readable UTF-8 text and is
terminated with at least one NULL character. This optional field is normally
provided by the OpenVNET client during registration. However, network
management application can update this field as required.
6.4.5 OpenVNET .VNET WEBSERVICE Object Node Port Name
This 64-bit identifier uniquely defines the fabric port. If the
OpenVNET client is attached to a Virtual Channel fabric port with a
registered Port Name, then that fabric Port Name shall be indicated
in this field. This field is included in the .VNETP for
compatibility with Virtual Channel fabric services and topologies.
The client Port may itself be registered as a port in the OpenVNET. In
that case, the Local Daemon Port Name (LWWN) attribute of service attached
ports will match the Port Name (WWPN) of the client Port registration.
6.4.6 OpenVNET .VNET WEBSERVICE Object Proxy
This optional field is the requested hard address 24-bit NL Port
Identifier, included in the .VNETP for compatibility with Fibre
Channel Arbitrated Loop services and topologies.
6.4.7 OpenVNET .VNET WEBSERVICE Object Port IP Address
The Virtual Channel IP address associated with the OpenVNET .VNET WEBSERVICE
Object Node. This optional field is included for compatibility with Virtual
Channel.
When an IPv4 value is contained in this field, the most significant
12 bytes are set to 0x00. This value is provided by the OpenVNET
client.
6.4.8 OpenVNET .VNET WEBSERVICE Object Class of Service (COS)
This 32-bit bit-map field indicates the Virtual Channel COS types that
are supported by the registered port. This field is provided by a
Virtual Channel-based OpenVNET client. The COS values are equivalent to
Virtual Channel COS values. The valid COS types, and associated bit-
map, are listed in the following table:
Class of Service Description Bit-Map
---------------- ----------- ---------
2 Delivery Confirmation Provided bit 2 set
3 Delivery Confirmation Not Provided bit 3 set
RESERVED other
6.4.9 OpenVNET .VNET WEBSERVICE Object Types
This 32-byte field indicates the VNETP protocol types supported by
the associated port. This field for OpenVNET .VNET WEBSERVICE Object Node is
provided by the OpenVNET client. This field can be used to support Virtual
Channel.
6.4.10 OpenVNET .VNET WEBSERVICE Object Descriptor
A variable-length text-based description of up to 256 bytes, that is
associated with the OpenVNET-registered service port in the network.
This optional field for OpenVNET .VNET WEBSERVICE Object ports is provided by
the OpenVNET client.
This field can be used to support Virtual Channel services. This field
can be used to support Virtual Channel .
6.4.11 OpenVNET .VNET WEBSERVICE Object Features
This is a 128-byte array, 4 bits per type, for the VNETP protocol
types supported by the associated port. This optional field for
OpenVNET .VNET WEBSERVICE Object ports is provided by the OpenVNET client.
This
field can be used to support Virtual Channel.
6.4.12 OpenVNET .VNET WEBSERVICE Object Node SCN Bitmap
This optional field is provided by the OpenVNET client. It indicates
the events that the OpenVNET .VNET WEBSERVICE Object Node is interested in.
These events can cause SCN to be generated.
Bit Field Flag Description
--------- ----------------
0 CHANGE IN DD MEMBERSHIP
1 CHANGE IN NETWORK
2 CHANGE IN CLIENT REGISTRATION PARAMETERS
3 CLIENT ADDED
4 CLIENT REMOVED
All others reserved.
6.4.13 OpenVNET .VNET WEBSERVICE Object Node Certificat
- [Savannah-hackers] savannah.gnu.org: submission of openvnet,
gsun <=