WO1995013676A1 - Systeme de communication avec un reseau incluant un ensemble d'administration - Google Patents

Systeme de communication avec un reseau incluant un ensemble d'administration Download PDF

Info

Publication number
WO1995013676A1
WO1995013676A1 PCT/FR1994/001275 FR9401275W WO9513676A1 WO 1995013676 A1 WO1995013676 A1 WO 1995013676A1 FR 9401275 W FR9401275 W FR 9401275W WO 9513676 A1 WO9513676 A1 WO 9513676A1
Authority
WO
WIPO (PCT)
Prior art keywords
administration
message
imd
module
layers
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/FR1994/001275
Other languages
English (en)
Inventor
Valérie CLEMENT
Régis MOURET
Nathalie Saint-Paul
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bull SAS
Original Assignee
Bull SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull SAS filed Critical Bull SAS
Priority to EP95900188A priority Critical patent/EP0728392B1/fr
Priority to US08/624,416 priority patent/US5793958A/en
Priority to DE69427198T priority patent/DE69427198T2/de
Priority to JP7513623A priority patent/JP2888642B2/ja
Publication of WO1995013676A1 publication Critical patent/WO1995013676A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/24—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using dedicated network management hardware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play

Definitions

  • the present invention relates to a communication system with a network implementing a communication code belonging to a plurality of open systems interconnection models, this system comprising a set of administration of the different layers of the code. It is applicable to all types of networks, in particular of the FDDI type, standardized with the ANSI, under the reference X3T9-5 and with the ISO. (International Organization for Standardization).
  • Modern networks operate according to a plurality of reference models which remain similar with regard to the definition of their architecture in the form of standardized layers.
  • OSI Open Systems Interconnection
  • ISO / DSA ISO / DSA
  • IPS IPS
  • the OSI model there are seven layers of different activities, the lowest layer (layer 1) corresponding to the physical transmission of signals and the high layer (layer 7) corresponding to the functions performed by the programs.
  • application more simply called application
  • the users of the network in question are seven layers of different activities, the lowest layer (layer 1) corresponding to the physical transmission of signals and the high layer (layer 7) corresponding to the functions performed by the programs.
  • application more simply called application
  • communication systems with a network are constituted by the association of a computer, also called host system, and a communication processor.
  • the purpose of the communication processor is to perform part of the management of communications with the other terminals of the network. As such, it supports the management of the lower layers of each of the reference models.
  • Such a communication system is for example described in the French patent application N ° 93 02902 filed on 12.03.93 by the applicant company under the title "Communication system with a network”, or in the French patent application N ° 93 08968 filed by the requesting Company on 07.21.93 under the title "communication system with a network and access protocol to the transport supplier belonging to this system”.
  • These two patent applications more specifically describe the software structure of such a system of communication.
  • the description of the hardware structure of such a system will also be found in French patent application No. 92 1 5521, the title of which is "data transmission system between a computer bus and a network” filed on 22.1 2.92 by the same plaintiff.
  • FIGS. 1 a and 1 b The general structure of such an extremely simplified communication system comprising at least one communication processor (such a communication system can contain several communication processors which can communicate with several networks of different types) is shown in FIGS. 1 a and 1 b.
  • Such a communication system here called, SCI implements, by means of the host system HOST, the high CH layers of any one of the reference models OSI, ISO / DSA, IPS (the latter being able to rely as well on a network service in connected mode than on a network service in non-connected mode: the connected mode which is designated by the acronym CONS, Anglo-Saxon acronym of Connected Oriented Network service, and the non-connected mode than the the acronym CNLS, the Anglo-Saxon acronym for Connection Less Network Service, is based on ISO standards 9878 and 8208 for the former and 8473 and 9542 for the latter, these standards defining the associated routing mechanisms and protocols).
  • the three upper layers C5 to C7 of the OSI model have been shown by way of example.
  • the CH layers communicate with the lower layers CB, namely C4 to C2 of these same models.
  • These layers can be implemented by one or more communication processors.
  • SCI consists of the host HOST associated with the communication processors PCj, PCj which can be of different types, their common point being to implement the low layers CB.
  • the processor PCj is connected to a network REj while PCj is connected to a network REj, these last two networks can be of different types.
  • both PCi and PCj can implement transport layers based either on a network service in RCONS connected mode (ISO / DSA or TCP model) or on a network service in RCLNS non-connected mode (model UDP).
  • the CH layers of HOST communicate with the low layers CB, implemented by a plurality of processors NCC type communication, namely NCC-j, NCC2, NCC
  • NCC type communication namely NCC-j, NCC2, NCC
  • RE2 which can be either identical or of different types, where the transport layers can be supported either on network services in connected mode or on services in non-connected mode.
  • the host HOST comprises an operating system SE which implements the high layers CH while the communication processors PCj, PCj in FIG. 1a, NCC-j in FIG. 1b respectively include the operating systems SEj, SEj , SE-
  • An example of an operating system for communication processors such as PCj, PCj, NCCi is for example described in application No. 91 08907 filed on July 15, 1991 by the applicant, under the title "Operating system for universal device coupling of a computer bus to a specific network link ".
  • the SCI communication system includes means of access to the transport supplier of the layer C4 allowing the lower part of the upper layers CH, here arranged at the lower part of the layer C5, to communicate with the upper layer C4.
  • a TPAM module belonging to a telecommunications server which serves as an interface between all of the high CH layers and the link channel between the host HOST and the communication processor (s),
  • FIG. 1a it has been assumed that the physical transfer of the data between the bottom of the high layers CH and the top of the transport layer C4 is effected by means of any safe channel not allowing loss of message, whereas in FIG. 1 b, this transfer is, for example, carried out by means of a bus of the MULTIBUS II type, called here PSB (standard IEEE 1296).
  • PSB standard IEEE 1296
  • any communication system and more precisely in any communication processor, the user needs to know at all times, the state in which each of the layers of the communication code is, and even each of the objects located at the inside the communication layers.
  • an object belonging to a layer of a communication code is constituted by a set of functionalities which works for the same purpose: thus, for example, the set of functionalities used to define a connection is an object.
  • an object consists of a data table located in memory, or a set of data tables.
  • An attribute or a parameter defines a characteristic of an object.
  • An object can therefore be defined by a set of attributes.
  • a set of attributes for which each attribute has a value is also called an object instance.
  • the state of an object or a layer of a communication code depends on the moment when it is considered. It can be in a communication state with other layers, or it can be in a configuration or initialization state.
  • any communication system generally includes an administration set enabling it to know the state in which each of the layers or each of the objects of 'a diaper.
  • the communication system with a network implementing a communication code belonging to a plurality of open system interconnection models, the work of which is organized by at least one operating system associated with a plurality of applications, the purpose of which is to transmit or receive data necessary for applications, to or from the network, comprising a set administration of the different layers of the code, is characterized in that this set includes:
  • an administration module allowing access to all administrative information, within each of the layers of the code
  • FIGS. 1 a and 1 b recalls what are the various essential constituent elements of a communication system, to which the invention applies,
  • FIG. 2 shows the set of software modules included in the communication processor, this set comprising the administration set specific to the system according to the invention
  • FIG. 3 shows more generally, the structure of any communication system according to the invention
  • FIG. 4 shows the structure of a message specific to the administration assembly belonging to the communication system according to the invention
  • FIG. 5 shows the internal structure of each of the administration modules belonging to the administration set of the communication system according to the invention.
  • FIG. 2 shows the ELC communication software assembly belonging for example to one of the communication processors NCCi, NCC2, NCC3 already described in any one of the three aforementioned patent applications.
  • This ELC software set is part of the communication system according to the invention, a system which we will designate in the same way as in FIG. 1, namely SCI.
  • the ELC set includes:
  • a CC communication code comprising for example three stacks of communication layers specific to different reference models, namely the OSI model, the ISO / DSA model, and the IPS model. These different modules are respectively called MOSI, MDIWS, MIPS. They are more specifically related to layers C4 and C3.
  • the communication code also includes the layer C2 also called LLC1 which is common to the three modules MOSI, MDIWS, MIPS.
  • a second LMAI2 administration interface made up in fact of two identical administration interfaces, namely LMAI21 and LMAI22 respectively providing the interface between the IMD administration module and each of the three communication modules, MOSI, MDIWS, MIPS on the one hand and with the Hl interface on the other.
  • the link between the CONFD configurator and the first LMAh administration interface on the one hand, and the links between the latter and each of the three MOSI, MDIWS and MIPS modules is carried out using "STREAMS" type links, more specifically called ADM STREAMS.
  • the links between the IMD administration module and each of the two interfaces LMAI21, LMAI22 as well as the links between these last two interfaces and the three communication modules MOSI, MDIWS and MPIS on the one hand and the interface Hl on the other hand are performed by means of "STREAMS" type links, more specifically IM STREAMS, which are administrative type links.
  • the communication layers C2, C3, C4 communicate with each other in pairs through primitive functions allowing two neighboring layers to communicate with each other.
  • the layers C2 and C3 communicate with each other through the set of functions of STREAM ST2 type while the layers C3 and C4 communicate through the set of functions ST3.
  • C4 communicates with the interface H1 via a set of functions SH.
  • These sets of functions are also STREAM type functions.
  • the set of functions ST2, ST3, SH, ADM STREAM, and IM STREAMS, are defined in the following documents:
  • each of the communication layers comprises specific administrative entities, entities whose role is to organize the administrative work of each of the communication layers belonging to the communication code CC.
  • the MOSI module comprises the administrative entities LME * ⁇ and LME1 2 relating respectively to the layers C4 and C3
  • the MDIWS module comprises the administrative entities LME21 and LME22 relating to the layers C4 and C3.
  • MIPS module includes a single interface administrative IAM relating to C4 and C3 (see below).
  • the C2 layer common to OSI and IPS has the LME4 administrative entity.
  • FIG. 3 shows the more general structure of a communication system according to the invention SCM where the two entities constituted by the host system HOST and the communication processor NCC1 are combined into one.
  • a CONFD configuration module whose role is strictly similar to that of Figure 2
  • an IMD administration module whose role is strictly identical to that of Figure 2
  • a first administration interface LMh whose role is identical to the administration interface LMAh of FIG. 2
  • a second administration interface LMI2 whose role is strictly identical to that of the administration interface LMAI2 of FIG. 2.
  • the first administration interface LMh provides the link between the configuration module CONFD and each of the administration entities of the layers C6 to C2 via control STREAM of the ADM STREAM type.
  • the first interface also provides the link via a STREAM, ADM STREAM with the IMD administration module.
  • the second administration interface LMI2 provides the connection between the administration module IMD and each of the administration entities of the layers C7 (presentation layer) to C2 with the connection means of the IM STREAM type.
  • the administrative entities of layers C7 to C2 are respectively designated by ME7 to ME2.
  • FIG. 3 shows the administration entities ME31 and ME32 which are the administration entities of the layers C3 relating respectively to a network operating according to the connected mode (Connection Oriented) and according to the unconnected mode (Connection Less).
  • the link between ME4 and both ME31 and ME32 is provided by known STREAM type links.
  • each layer administration entity manages a set of objects each described by a plurality of attributes.
  • These sets of objects conform to the various standards defining each of the reference models, whether it is the OSI model, the ISO / DSA model, or even the IPS model. It is also possible to implement in the communication processor or in the communication system SCh, standard management protocols, such as the SNMP, CNMA, or even OSI / NMFORUM protocols.
  • the IMD module works in conjunction with the operating system of either the communication processor or the SCh communication system as a whole, and is responsible for routing messages to or from u the entities and the maintenance and configuration tools. and administration which are also found inside these layers. As we have seen above, all the exchanges between the administration entities and the IMD module are based on communications by means of STREAM functions.
  • first and second administration interfaces namely LMAh or LMAI2 in FIG. 2, LMh and LMI2 in FIG. 3, they define the dialogs between the IMD module, the CONFD configurator and the various administration entities of the layers located inside communication codes.
  • Figure 4 shows the general form of a message. Conforms to the STREAM standard used to transport the primitive administration functions, a primitive defining the meaning of a message.
  • a message includes a first block, designated by M-PROTO followed or not by a block, called M-DATA.
  • Each data structure C defines the global exchange of information between the entities and the IMD module.
  • This data structure C is contained inside the block M-PROTO.
  • the information associated with the primitive which defines its meaning is carried in the M-DATA block.
  • M-PROTO and M-DATA are encoded in an ASN.1 type format to meet the requirements of the IMD module.
  • the type of information coded ASN.1 is as follows: - a status list, also called Status-list: this list provides the states of the different entities or objects that we wanted to manage.
  • Param-list which includes the list of the different entities or objects that we want to manage.
  • Ident-list which includes the list of identifiers of the objects whose values we want to recover.
  • a module object for example a module object such as MOSI, MDIWS, MIPS contains layer objects, i.e. either a layer 4 object or a layer 3 object, which contains a plurality of objects which are either connection objects, or selection objects, or also so-called IVMO objects which is the acronym for Initial Value Manage Object, and which consequently are objects defining the initial values of each object of layers.
  • layer objects i.e. either a layer 4 object or a layer 3 object, which contains a plurality of objects which are either connection objects, or selection objects, or also so-called IVMO objects which is the acronym for Initial Value Manage Object, and which consequently are objects defining the initial values of each object of layers.
  • a module or an administrative entity is identified by an integer called SUBSYSTEM-id.
  • SUBSYSTEM-id For the entities contained inside the operating system, whether it is inside the operating system of the communication processor, or even more generally inside the operating system of a communication system such as SCh, the module identifier is given by the CONFD configurator at the time of initialization. The IMD module uses this identifier to send messages to the correct module or to the entity within a layer.
  • this field defines the identifier of the module which contains this administered object.
  • this identifier defines the administrative type of the object.
  • - OBJECT-name here it is either, for the OSI model an identifier giving an internal name given by the module that contains the object, or, for the IPS model of an integer (O to n) allowing to recognize the (O to n) first parameters conveyed in the M-DATA block, as being particular parameters used for the search for the instance of the requested object (in the case where the module cannot be named).
  • the implementation of the module assumes that administered objects of the same type that are contained in it have different names.
  • PRIM-name and PRIM-type identify a request from the administration interface or a response.
  • the IM-userid parameter is provided by the IMD module and allows the latter to correctly route the response to the entity that provided the request. It is clear that this last parameter has the same value whether it is the request or the response.
  • OBJECT-subtype which is used to distinguish sets of objects of the same type but which do not support the same administrative requests.
  • connection and IVMO type objects With regard to selection, connection and IVMO type objects, the object immediately above them represents the layer object that contains them. He is identified. by the following three fields:
  • - OBJECT - upname is the name of the top object.
  • the administration messages which are numbered from 1 to 21 (which are of type 1 to 21) are the following:
  • This message is a request message sent to an administrative entity by the IMD module, in order to initialize the dialogue between the latter and this module. It is the first message sent to the entity by the module in question.
  • the entity responds by sending one (or more) message called ADM-BIND-OBJ-IND which indicates what type of object the entity in question is administering.
  • ADM-BIND-OBJ-IND indicates what type of object the entity in question is administering.
  • ADM-BIND-OBJ-IND When the entity has sent to IMD all of the ADM-BIND-OBJ-IND messages corresponding to all of the objects it manages, it sends an ADM-OK-ACK message to IMD to signal the end of its reply. No other message can be sent by the IMD module to an administration entity before receipt of this last acknowledgment message.
  • the entity receiving the request message then assigns a STREAM type link to administrative information.
  • This message is returned in response to the previous one by the administrative entity to which the IMD module is addressed. It is sent on a STREAM function of type IM-STREAMS. The administration entity sends only one such message per type of object administered.
  • This message ends the initialization dialog between the IMD module and the administrative entity. It is sent on an IM-Streams after one or more type 2 messages in response to the type 1 message.
  • This message can also be used to indicate to the IMD module that a previously sent message has been successfully received by an administration entity when for this latter no other response is defined.
  • This message tells IMD that a previously sent message has not been successfully received by an administrative unit and cannot be processed due to a system error. This message indicates the reasons for the fault. The reception of this message also indicates to IMD that no action was taken on the message which caused this negative response.
  • This message is sent by the module specified in the OBJECT-type field.
  • selection and IVMO objects it provides the names of the objects whose type is specified in the OBJECT-type field and which are associated with the layer object identified by the OBJECT-uptype, OBJECT-upname, SUBSYSTEM.
  • This message is sent by a PILE entity (stacking of layers) to the IMD module in response to its type 5 message. It gives the list of administrative names to object instances for a given type of object.
  • This message is sent by IMD to request an administered entity to return the value of the attributes of an object instance. If a list of attributes is provided, the list of attribute values must be returned to the IMD module. If no list is provided, all attribute values must be returned. An error is indicated in the response provided by the administrative entity if any attribute cannot be read.
  • ADM-GETNEXT-REQ message is sent by the administrative entity to IMD in response to the previous type 7 message. It returns the attribute values of the required object instance. An error is indicated if at least one attribute cannot be read.
  • This message allows an administrative entity to obtain the attributes of all the instances of an object without knowing the names of these instances. It is therefore not necessary to send a type 5 message to obtain the name of the object instance.
  • the list of object names is managed in an arbitrary order by the entity, this order depending on the implementation of the latter inside the layer.
  • This message is sent by an administrative entity in response to the type 9 message. It returns the requested object attribute value to the IMD module. An error is indicated if these attributes cannot be read.
  • This message is sent by IMD to an administrative entity on an IM STREAM. It gives a new value to the attributes of an object instance. This applies to attributes that are defined to be able to be written. Their list provided, in the M-DATA part contains the identifiers of the attributes and the associated values that are given to the attribute values which must be replaced.
  • This message is sent by an administration entity in response to the previous message of type 1 1. It indicates whether the attribute value change operation required by the type 1 message 1 has been successful or not.
  • This message is sent to the administrative entities by IMD. It allows to check if the value of several attributes of an object instance can be simultaneously modified to have a new value. Attribute values are not changed by this message.
  • ADM-TEST-ACK message This message is an acknowledgment message sent by an administration entity in response to the previous type 13 message.
  • This message is sent by IMD to the administrative entities.
  • the functions of this message depend on the type of action mentioned in the PRIM-type field.
  • This message is sent by an administration entity in response to the previous type 1 message 5 and indicates the success or failure of this last request.
  • This message requests an administrative entity to create a new object instance. It is not allowed for all types of object. For the creation of an object, a certain number of attributes of the object are required and must be supplied in the request. The name of the object to be created is provided by the module which will administer it. This name is provided in the response to the request made by this message.
  • This message is sent by an administration entity in response to the previous type 17 message and it allows acknowledgment if the request is successful.
  • This message requests an administrative entity to remove an object instance.
  • This message is sent by an administrative entity in response to the previous type 19 message to acknowledge the success or failure of the request corresponding to this type 19 message.
  • ADM-EVENT-IND This message indicates to the IMD module that an event is taking place in the layer entity. For the administration module, there is no acknowledgment when it receives the indication that an event has occurred in said layer entity.
  • the OBJECT-type field is an object class that is made up of parameters.
  • An IPS object is defined by its OBJECT-type field and by an instance of this class. IF it is a simple object (mono-instance) the identification is given simply by the field (OBJECT-type).
  • An instance is defined by the values of selection parameters. The latter which give an identification and a value are transmitted in the block of M-DATA messages of the request.
  • the OBJECT-name field contains the number of parameters used for the selection. Thus, if necessary, the first instances of the M-DATA message block are the selection parameters.
  • the M-DATA message blocks are coded in ASN.1.
  • Annex 2 is strictly identical to the presentation of Annex 1.
  • ADM-SUBSYSTEM-ID This message is sent by the CONFD configurator upon the opening of each of the modules of the communication processor in FIG. 2 or by each of the modules of the SCH system of FIG. 3, either by being conveyed by an ADM STREAM or by an IM STREAM . Any entity that wants to be administered can take this message into account and must know how to understand it.
  • This message is sent by CONFD just after the opening of the Stream of command of a module. This stream is then assigned by said module to the CONFD configurator.
  • This message is returned by the module to the configurator if the request for the previous type 23 message has been accepted.
  • This message is returned by the module to the CONFD configurator if the request indicated by the type 23 message has been refused.
  • This message is sent to the configurator on an ADM STREAM by a module, to request a new Stream type link to another module.
  • This is the case, for example, for the creation of stream links between the C4 layer and the C3 layer of the OSI model. This link is to be created dynamically as the standards provide.
  • This message is sent to the CONFD configurator by a module to request the disconnection of a module.
  • a module to request the disconnection of a module.
  • This is the case for example, in the OSI model, of a C4 layer (so-called COTP layer) which requests the disconnection of a C3 layer (so-called CLNP layer), that is to say which requests the link to be broken streams between them.
  • ADM-STREAM-ERROR message This message is sent by the CONFD configurator to the module to which the configurator addressed itself if an error occurred during the sending of a request delivered by the ADM-STREAM-OPEN message (type 26 message).
  • This message is sent by the configurator in response to the module to which it is addressed, if no error has occurred during the sending of the request corresponding to the message of type 26.
  • This message is sent by the configurator in response to the module to which it is addressed, if no error has occurred during the sending of the request corresponding to the message ADM-STREAM-CLOSE (message of type 27).
  • This message is returned by the module to the configurator after sending a request corresponding to one or other of the messages defined in 29 or 30.
  • This message is returned by the module to the configurator after sending a request corresponding to one or other of the messages of type 29 or 30. It corresponds to a negative acknowledgment.
  • the ADM-SUBSYSTEM-ID message is only sent to IAM (specific internal module, serving as an administrative interface between layers C3 and C4 of the IPS type stack, and the administrative commands issued by the administrative antenna) by the CONFD configurator.
  • IAM specific internal module, serving as an administrative interface between layers C3 and C4 of the IPS type stack, and the administrative commands issued by the administrative antenna
  • This internal module is, by construction, the administrative interface '30 of all layers of the MIPS module.
  • the administrative interface '30 of all layers of the MIPS module Regarding the configuration for the FDDI network, standard messages of known SMT type are used.
  • appendices 3, 4, 5, 6 summarize what was said above in the description of each of the messages.
  • the CONFD configurator located in the central part of the figure has been symbolized in this vertical line by a vertical line, while the entity considered, that is to say for example an administration entity of one of the layers C4 or C3 of one of the MOSI, MIPS, MDIWS modules is represented by a vertical line on the right of the figure.
  • Messages are symbolized by arrows, the direction of the arrow indicating the direction in which the message is sent.
  • Annex 4 shows the exchange of messages between the IMD module and any entity and there are practically all of the administration messages described above.
  • Annex 5 describes the two messages which are exchanged between the IMD module and any entity when a message sent by IMD is not accepted by the layer entity due to an error preventing the correct processing of the message.
  • Annex 6 shows the exchange of messages between CONFD, IMD and a PILE entity during the initialization phase.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)

Abstract

Système de communication (SCI1) avec un réseau (RE, ...) mettant en ÷uvre un code de communication (CC) appartenant à une pluralité de modèles d'interconnexion (OSI, IPS), comprenant un ensemble d'administration (C4, C3, C2) du code (CC) comprenant des modules de communication appartenant à divers modèles caractérisé en ce que cet ensemble comprend: un configurateur (CONFD) établissant lors de l'initialisation du système, l'empilement des différentes couches du code; un module d'administration (IMD) permettant l'accès à toutes informations administratives à l'intérieur de chacune des couches; une première interface d'administration (LAMI1, LMI1) disposée entre le configurateur (CONFD) d'une part, et différentes entités d'administration, et le module d'administration (IMD) d'autre part; une seconde interface d'administration (LMAI2, LMI2) disposée entre le module d'administration (IMD) et les entités d'administration (LME11, LME12). Applicable aux processeurs de communication.

Description

S STEME DE COMMUNICATION AVEC UN RESEAU INCLUANT UN ENSEMBLE D'ADMINISTRATION.
La présente invention concerne un système de communication avec un réseau mettant en oeuvre un code de communication appartenant à une pluralité de modèles d'interconnexion de systèmes ouverts, ce système comprenant un ensemble d'administration des différentes couches du code. Elle est applicable à tous types de réseaux, notamment de type FDDI, normalisé à l'ANSI, sous la référence X3T9-5 et à l'I.S.O. (Organisation Internationale de Normalisation).
Les réseaux modernes fonctionnent suivant une pluralité de modèles de référence qui restent voisins en ce qui concerne la définition de leur architecture sous forme de couches normalisées. Parmi ces modèles, les plus connus sont les modèles OSI (sigle anglo-saxon signifiant Interconnexion de systèmes ouverts), ISO/DSA, IPS (on rappelle que le modèle IPS (sigle anglo-saxon signifiant Suite de Protocoles Internet) inclut sous la même dénomination les sous-modèles TCP, UDP, IP, ICMP, notamment). Ainsi, dans le modèle OSI, il y a sept couches d'activités différentes, la couche la plus basse (couche 1 ) correspondant à la transmission physique des signaux et la couche haute (couche 7) correspondant aux fonctions réalisées par les programmes d'application (plus simplement appelés application) et les utilisateurs du réseau considéré.
Dans la pratique courante, les systèmes de communication avec un réseau sont constitués par l'association d'un ordinateur, encore appelé système hôte, et d'un processeur de communication. Le but du processeur de communication est d'effectuer une partie de la gestion des communications avec les autres terminaux du réseau. A ce titre, il prend en charge la gestion des couches inférieures de chacun des modèles de référence.
Un tel système de communication est par exemple décrit dans la demande de brevet français N° 93 02902 déposée le 12.03.93 par la Société demanderesse sous le titre "Système de communication avec un réseau", ou encore dans la demande de brevet français N° 93 08968 déposée par la Société demanderesse le 21.07.93 sous le titre "système de communication avec un réseau et protocole d'accès au fournisseur de transport appartenant à ce système". Ces deux demandes de brevet décrivent plus particulièrement la structure logiciel d'un tel système de communication. On trouvera encore la description de la structure matérielle d'un tel système dans la demande de brevet français N° 92 1 5521 dont le titre est "système de transmission de données entre un bus d'ordinateur et un réseau" déposée le 22.1 2.92 par la même demanderesse.
La structure générale d'un tel système de communication extrêmement simplifiée comprenant au moins un processeur de communication (un tel système de communication peut contenir plusieurs processeurs de communication pouvant communiquer avec plusieurs réseaux de types différents) est montrée aux figures 1 a et 1 b.
Un tel système de communication, ici dénommé, SCI met en oeuvre, au moyen du système hôte HOST, les couches hautes CH de l'un quelconque des modèles de référence OSI, ISO/DSA, IPS (ce dernier pouvant s'appuyer aussi bien sur un service de réseau en mode connecté que sur un service de réseau en mode non connecté : le mode connecté que l'on désigne par le sigle CONS, sigle anglo-saxon de Connected Oriented Network service, et le mode non connecté que l'on désigne par le sigle CNLS, sigle anglo- saxon de Connection Less Network Service, s'appuient sur les normes ISO 9878 et 8208 pour le premier et 8473 et 9542 pour le second, ces normes définissant les mécanismes et protocoles de routage associés).
Si l'on se réfère aux figures 1 a et 1 b, on a représenté à titre d'exemple les trois couches hautes C5 à C7 du modèle OSI. Les couches CH communiquent avec les couches basses CB, à savoir C4 à C2 de ces mêmes modèles. Ces couches peuvent être mises en oeuvre par un ou plusieurs processeurs de communication. A la figure 2, on a supposé que SCI était constitué de l'hôte HOST associé aux processeurs de communication PCj, PCj qui peuvent être de différents types, leur point commun étant de mettre en oeuvre les couches basses CB. Le processeur PCj est relié à un réseau REj alors que PCj est relié à un réseau REj, ces deux derniers réseaux pouvant être de types différents. Par ailleurs, aussi bien PCi que PCj peuvent mettre en oeuvre des couches de transport s'appuyant soit sur un service de réseau en mode connecté RCONS (modèle ISO/DSA ou TCP) soit sur un service de réseau en mode non connecté RCLNS (modèle UDP) .
A la figure 1 b, les couches CH de HOST communiquent avec les couches basses CB, mises en oeuvre par une pluralité de processeurs de communication de type NCC, à savoir NCC-j , NCC2, NCC|< connectés à des réseaux RE-) , RE2, Rk qui peuvent être soit identiques, soit de types différents, où les couches de transport peuvent s'appuyer soit sur des services de réseau en mode connecté soit sur des services en mode non connecté.
L'hôte HOST comprend un système d'exploitation SE qui met en oeuvre les couches hautes CH alors que les processeurs de communication PCj, PCj à la figure 1a, NCC-j à la figure 1b comprennent respectivement les systèmes d'exploitation SEj, SEj, SE-| . Un exemple de système d'exploitation des processeurs de communication tels que PCj, PCj, NCCi est par exemple décrit dans la demande N°91 08907 déposée le 15.07.91 par la demanderesse, sous le titre "Système d'exploitation pour dispositif universel de couplage d'un bus d'ordinateur à une liaison spécifique d'un réseau".
Le système de communication SCI comporte des moyens d'accès au fournisseur de transport de la couche C4 permettant à la partie inférieure des couches hautes CH, ici disposée à la partie inférieure de la couche C5, de communiquer avec le haut de couche C4. Ces moyens d'accès sont décrits dans la demande N° 93 08968 précitée et sont seulement ici résumés :
- côté hôte, un module TPAM, appartenant à un serveur de télécommunication qui sert d'interface entre l'ensemble des couches hautes CH et le canal de liaison entre l'hôte HOST et le ou les processeurs de communication,
- du côté des processeurs de communication par une interface Hl également décrite dans cette même demande, ou par toutes interfaces jouant un rôle équivalent à Hl,
- des unités d'accès dont l'ensemble est désigné par TPA, symbolisé aussi bien à la 1a qu'à la figure 1b par un rectangle en trait interrompu, relayant le bas de la couche C5 et le haut de la couche C4.
A la figure 1a, on a supposé que le transfert physique des données entre le bas des couches hautes CH et le haut de la couche de transport C4 s'effectue au moyen d'un quelconque canal sûr n'autorisant pas la perte de message, alors qu'à la figure 1 b, ce transfert est, par exemple, effectué au moyen d'un bus de type MULTIBUS II, appelé ici PSB (norme IEEE 1296).
Dans tout système de communication, et plus précisément dans tout processeur de communication, l'utilisateur a besoin de connaître à tout instant, l'état dans lequel se trouve chacune des couches du code de communication, et même chacun des objets se situant à l'intérieur des couches de communication.
On rappelle qu'un objet appartenant à une couche d'un code de communication est constitué par un ensemble de fonctionnalités qui travaille dans un même but : ainsi, par exemple, l'ensemble des fonctionnalités servant à définir une connexion est un objet. Physiquement, un objet est constitué par une table de données située en mémoire, ou un ensemble de tables de données.
Un attribut, ou encore un paramètre définit une caractéristique d'un objet. Un objet pourra donc être défini par un ensemble d'attributs. Un ensemble d'attributs dont chaque attribut a une valeur est également appelé instance d'objet. L'état d'un objet ou d'une couche d'un code de communication dépend de l'instant où on la considère. Elle peut se trouver en état de communication avec d'autres couches, ou encore être dans un état de configuration ou d'initialisation. Pour savoir, à chaque instant, où en sont chacun des objets ou chacune des couches d.e communication, tout système de communication comporte généralement un ensemble d'administration lui permettant de connaître l'état dans lequel se situe chacune des couches ou chacun des objets d'une couche.
C'est précisément l'objet de la présente invention que de définir un tel ensemble d'administration pour tout système de communication tel que ceux montrés aux figures 1 a et 1 b.
Selon l'invention, le système de communication avec un réseau mettant un oeuvre un code de communication appartenant à une pluralité de modèles d'interconnexion de systèmes ouverts, dont le travail est organisé par au moins un système d'exploitation associé à une pluralité d'applications, et dont le but est de transmettre ou de recevoir des données nécessaires aux applications, vers ou depuis le réseau, comprenant un ensemble d'administration des différentes couches du code, est caractérisé en ce que cet ensemble comprend :
- un configurateur établissant, lors de l'initialisation du système, l'empilement des différentes couches au moyen de liens de types STREAMS entre celles-ci,
- un module d'administration permettant l'accès à toute information d'ordre administratif, à l'intérieur de chacune des couches du code,
- une première interface d'administrαiiυn entre le module d'administration et des entités d'administration des couches situées à l'intérieur de celles-ci,
- une seconde interface d'administration entre le configurateur d'une part, et les différentes entités et le module d'administration d'autre part.
D'autres caractéristiques et avantages de la présente invention apparaîtront dans la description suivante donnée à titre d'exemple non limitatif et en se référant aux dessins annexés.
Sur ces dessins :
La figure 1 . composée des figures 1 a et 1 b rappelle quels sont les différents éléments constitutifs essentiels d'un système de communication, auquel s'applique l'invention,
La figure 2 montre l'ensemble des modules logiciels inclus dans le processeur de communication, cet ensemble comprenant l'ensemble d'administration propre au système selon l'invention,
La figure 3 montre de manière plus générale, la structure d'un système de communication quelconque selon l'invention,
La figure 4 montre la structure d'un message propre à l'ensemble d'administration appartenant au système de communication selon l'invention,
La figure 5 montre le structure interne de chacun des modules d'administration appartenant à l'ensemble d'administration du système de communication selon l'invention.
On se réfère à la figure 2. Cette figure montre l'ensemble logiciel de communication ELC appartenant par exemple à l'un des processeurs de communication NCCi , NCC2, NCC3 déjà décrit dans l'une quelconque des trois demandes de brevet précitées. Cet ensemble logiciel ELC fait partie du système de communication selon l'invention, système que nous désignerons de la même façon qu'à la figure 1 , à savoir SCI.
L'ensemble ELC comprend :
- un code de communication CC, comprenant par exemple trois empilements de couches de communication propres à des modèles de référence différents, à savoir le modèle OSI, le modèle ISO/DSA, et le modèle IPS. Ces différents modules sont appelés respectivement MOSI, MDIWS, MIPS. Ils sont plus spécifiquement relatifs aux couches C4 et C3. Le code de communication comprend encore la couche C2 encore appelée LLC1 qui est commune aux trois modules MOSI, MDIWS, MIPS.
- l'interface Hl entre le serveur de communication NCCD appartenant au système hôte HOST, et les couches basses CB ici représentées par les trois modules MOSI, MDIWS, MIPS. Le rôle de Hl et de NCCD est décrit plus en détail dans les demandes 93 02902 et 93 08968 précitées.
- l'interface HIN déjà décrite dans l'une quelconque des trois demandes de brevet précitées permet de faire communiquer l'interface Hl et la couche
C2 avec le système d'exploitation GPOS du processeur de communication appartenant au système de communication SCI selon l'invention.
- le module de configuration CONFD dont le rôle a été précisé plus haut,
- le module d'administration IMD, dont le rôle a été également précisé plus haut,
- une première interface d'administration LMAh disposée entre le configurateur CONFD et chacun des modules de communication MOSI, MDIWS, MIPS,
- une seconde interface d'administration LMAI2 composée en fait de deux interfaces d'administration identiques, à savoir LMAI21 et LMAI22 assurant respectivement l'interface entre le module d'administration IMD et chacun des trois modules de communication, MOSI, MDIWS, MIPS d'une part et avec l'interface Hl d'autre part.
La liaison entre le configurateur CONFD et la première interface d'administration LMAh d'une part, et les liaisons entre cette dernière et chacun des trois modules MOSI, MDIWS et MIPS s'effectue aux moyens de liaisons de type "STREAMS", plus spécifiquement appelées ADM STREAMS. Les liaisons entre le module d'administration IMD et chacune des deux interfaces LMAI21 , LMAI22 ainsi que les liaisons entre ces deux dernières interfaces et les trois modules de communication MOSI, MDIWS et MPIS d'une part et l'interface Hl d'autre part sont effectuées au moyen de liaisons de type "STREAMS", plus spécifiquement IM STREAMS, qui sont des liaisons de type administratif.
Par ailleurs, on rappelle que les couches de communication C2, C3, C4 communiquent entre elles deux à deux par l'intermédiaire de fonctions primitives permettant à deux couches voisines de dialoguer entre elles. Ainsi, les couches C2 et C3 communiquent entre elles par l'intermédiaire de l'ensemble de fonctions de type STREAM ST2 alors que les couches C3 et C4 communiquent par l'intermédiaire de l'ensemble de fonction ST3. Par ailleurs C4 communique avec l'interface Hl par l'intermédiaire d'un ensemble de fonctions SH. Ces ensembles de fonctions sont également des fonctions de type STREAM. L'ensemble des fonctions ST2, ST3, SH, ADM STREAM, et IM STREAMS, sont définis dans les documents suivants :
- Unix System V, release 4 -STREAM Programmer guide ATT issue 1 ,
- Unix System V, release 3.2 - STREAM Programmer guide ATT (ISBN : 0- 13-944810.-1 ) : 1989,
Par ailleurs, dans les modèles OSI, ISO/DSA chacune des couches de communication comprend des entités d'administration spécifiques, entités dont le rôle est d'organiser le travail d'administration de chacune des couches de communication appartenant au code de communication CC. Ainsi, le module MOSI comprend les entités d'administration LME*π et LME1 2 relatives respectivement aux couches C4 et C3, le module MDIWS comprend les entités d'administration LME21 et LME22 relatives aux couches C4 et C3. Le module MIPS comprend une seule interface administrative IAM relative à C4 et C3 (voir plus loin). La couche C2 commune à OSI et IPS possède l'entité d'administration LME4.
La figure 3 montre la structure plus générale d'un système de communication selon l'invention SCM où les deux entités constituées par le système hôte HOST et le processeur de communication NCC1 sont réunis en une seule. On peut observer sur cette même figure que l'on retrouve un module de configuration CONFD dont le rôle est strictement analogue à celui de la figure 2, un module d'administration IMD dont le rôle est strictement identique à celui de la figure 2, une première interface d'administration LMh dont le rôle est identique à l'interface d'administration LMAh de la figure 2, une seconde interface d'administration LMI2 dont le rôle est strictement identique à celui de l'interface d'administration LMAI2 de la figure 2.
Ainsi, la première interface d'administration LMh assure la liaison entre le module de configuration CONFD et chacune des entités d'administration des couches C6 à C2 par l'intermédiaire de STREAM de commande de type ADM STREAM. La première interface assure également la liaison par l'intermédiaire d'un STREAM, ADM STREAM avec le module d'administration IMD.
La seconde interface d'administration LMI2 assure la liaison entre le module d'administration IMD et chacune des entités d'administration des couches C7 (couche de présentation) à C2 aux moyens de liaison de type IM STREAM. Les entités d'administration des couches C7 à C2 sont respectivement désignées par ME7 à ME2. On a représenté sur la figure 3 les entités d'administration ME31 et ME32 qui sont les entités d'administration des couches C3 relatives respectivement à un réseau fonctionnant suivant le mode connecté (Connection Oriented) et suivant le mode non connecté (Connection Less). La liaison entre ME4 et aussi bien ME31 que ME32 est assurée par des liaisons de type STREAM connues.
II est bien entendu que le fonctionnement des systèmes de communication SCI de la figure 2 et SCh de la figure 3 est identique.
Aussi bien à la figure 2 qu'à la figure 3, chaque entité d'administration de couche, aussi bien LME1 1 à LME21 , LME4 et IAM, que les différentes entités ME7 à ME2, gère un ensemble d'objets décrits chacun par une pluralité d'attributs. Ces ensembles d'objets sont conformes aux différents standards définissant chacun des modèles de référence, qu'il s'agisse du modèle OSI, du modèle ISO/DSA, ou encore du modèle IPS. On peut également implémenter dans le processeur de communication ou dans le système de communication SCh , des protocoles de gestion standards, tels que les protocoles SNMP, CNMA, ou encore OSI/NMFORUM.
Le module IMD travaille en liaison avec le système d'exploitation soit du processeur de communication, soit du système de communication SCh dans son ensemble, et est chargé du routage des messages vers ou de uiς les entités et les outils de maintenance, de configuration et d'administration qui se trouvent également à l'intérieur de ces couches. Ainsi qu'on a pu le constater ci-dessus, tous les échanges entre les entités d'administration et le module IMD sont basés sur des communications aux moyens de fonctions STREAM.
Quant aux première et deuxième interfaces d'administration, à savoir LMAh ou LMAI2 à la figure 2, LMh et LMI2 à la figure 3, elles définissent les dialogues entre le module IMD, le configurateur CONFD et les différentes entités d'administration des couches situées à l'intérieur de codes de communication.
On considère désormais la figure 4 qui montre la forme générale d'un message .conforme au standard STREAM utilisé pour transporter les fonctions primitives d'administration, une primitive définissant le sens d'un message.
Un message comprend un premier bloc, désigné par M-PROTO suivi ou non par un bloc, appelé M-DATA. Chaque fonction primitive est formée par une structure de données spécifique dite structure C, qui est suivie ou non par un ensemble de données (terme anglo-saxon = buffer) qui contient l'information administrative échangée. Chaque structure de données C définit l'échange global d'informations entre les entités et le module IMD. Cette structure de donnée C est contenue à l'intérieur du bloc M-PROTO. l'information associée à la primitive qui définit le sens de celle-ci est transportée dans le bloc M-DATA. M-PROTO et M-DATA sont encodés dans un format de type ASN.1 pour répondre aux exigences du module IMD. Le type d'informations codé ASN.1 est le suivant : - une liste de status, encore appelée Status-list : cette liste fournit les états des différentes entités ou objets que l'on a voulu administrer.
- une liste appelée Param-list qui comprend la liste des différentes entités ou objets que l'on veut administrer.
- une liste dite Ident-list qui comprend le liste des identifiants des objets dont on souhaite récupérer les valeurs.
On se reporte à la figure 5 qui montre la hiérarchie des différents objets. Un objet de module, par exemple un objet d'un module tel que MOSI, MDIWS, MIPS contient des objets de couche, c'est-à-dire soit un objet de la couche 4 soit un objet de la couche 3, lequel contient une pluralité d'objets qui sont soit des objets de connexion, soit des objets de sélection, soit encore des objets dits IVMO qui est le sigle anglais de Initial Value Manage Object, et qui par conséquent sont des objets définissant les valeurs initiales de chaque objet de couches.
Un module ou une entité administrative est identifié par un entier appelé SUBSYSTEM-id. Pour les entités contenues à l'intérieur du système d'exploitation, que ce soit à l'intérieur du système d'exploitation du processeur de communication, ou encore plus généralement à l'intérieur du système d'exploitation d'un système de communication tel que SCh , l'identifiant du module est donné par le configurateur CONFD à l'instant de l'initialisation. Le module IMD utilise cet identifiant pour expédier les messages vers le module correct ou vers l'entité à l'intérieur d'une couche.
Un objet administré est identifié par trois champs qui sont les suivants :
- SUBSYSTEM-id : ce champ définit l'identifiant du module qui contient cet objet administré.
- OBJECT-type : cet identifiant définit le type administratif de l'objet.
- OBJECT-name : il s'agit ici soit, pour le modèle OSI d'un identifiant donnant un nom interne donné par le module qui contient l'objet, soit, pour le modèle IPS d'un entier (O à n) permettant de reconnaître les (O à n) premiers paramètres véhiculés dans le bloc M-DATA, comme étant des paramètres particuliers utilisés pour la recherche de l'instance de l'objet demandée (dans le cas où le module ne peut être nommé). L'implémentation du module suppose que les objets administrés de même type qui sont contenus dans celui-ci aient des noms différents.
Les paramètres communs à des primitives émises par toute interface d'administration (LMAI, LMI aux figures 2 et 3) sont les suivantes :
Les paramètres dénommés PRIM-name et PRIM-type identifient une demande de l'interface d'administration ou une réponse.
Le paramètre IM-userid est fourni par le module IMD et permet à ce dernier d'effectuer un routage correct de la réponse vers l'entité qui a fourni la demande. Il est clair que ce dernier paramètre à la même valeur qu'il s'agisse de la demande ou de la réponse.
Parmi les paramètres communs à toutes les primitives relatives aux interfaces d'administration, on trouve également les paramètres SUBSYSTEM-id, OBJECT-type et OBJECT-name définis ci-dessus.
Il existe également un autre paramètre appelé OBJECT-subtype qui est utilisé pour distinguer des ensembles d'objets du même type mais qui ne supportent pas les mêmes demandes administratives.
En ce concerne les objets de sélection, de connexion et de type IVMO, l'objet immédiatement supérieur à ceux-ci représente l'objet de couche qui les contient. Il est identifié. par les trois champs suivants :
- SUBSYSTEM-upid est l'identifiant de l'entité, c'est-à-dire de la couche qui contient l'objet supérieur,
- OBJECT-uptype est le type administratif de l'objet supérieur,
- OBJECT - upname est le nom de l'objet supérieur.
Il existe deux types de message utilisés par les modules CONFD, IMD, et LMAh , LMAI2, LMh , LMI2 à savoir d'une part les messages administratifs et d'autre part les messages de configuration.
On considère tout d'abord les différents messages administratifs. La liste de ceux-ci figure en annexe 1 pour les messages administratifs et en annexe 2 pour les message de configuration. Sur chacune de ces deux annexes, on a fait figurer dans une colonne le nom du message et dans les colonnes suivantes, le modèle de référence, à savoir, de type OSI, ou IPS ou encore de type FDDI auquel appartient le message . On a encore fait figurer dans les deux dernières colonnes de droite le nom de l'émetteur du message et le nom du récepteur du message.
Les messages d'administration qui sont numérotés de 1 à 21 (qui sont de type 1 à 21 ) sont les suivants :
1 . Message ADM-BIND-LAYER-REQ :
Ce message est un message de requête envoyé à une entité d'administration par le module IMD, en vue d'initialiser le dialogue entre cette dernière et ce module. C'est le premier message envoyé à l'entité par le module en question. L'entité répond en envoyant un (ou davantage) message appelé ADM-BIND-OBJ-IND qui indique quel type d'objet l'entité en question administre. Lorsque l'entité a envoyé vers IMD l'ensemble des messages ADM-BIND-OBJ-IND corrrespondant à l'ensemble des objets qu'elle gère, elle envoie un message ADM-OK-ACK vers IMD pour lui signaler la fin de sa réponse. Aucun autre message ne peut être envoyé par le module IMD à une entité d'administration avant réception de ce dernier message d'acquittement. L'entité qui reçoit le message de requête affecte alors une liaison de type STREAM à des informations d'administration.
2. Message ADM-BIND-OBJ-IND :
Ce message est renvoyé en réponse au précédent par l'entité d'administration à laquelle s'adresse le module IMD. Il est envoyé sur une fonction STREAM de type IM-STREAMS. L'entité d'administration envoie un seul message de cette nature par type d'objet administré.
3. Message ADM-OK-ACK :
Ce message termine le dialogue d'initialisation entre le module IMD et l'entité d'administration. Il est envoyé sur une IM-Streams après un ou plusieurs messages de type 2 en réponse au message de type 1 .
Ce message peut également être utilisé pour indiquer au module IMD qu'un message précédemment envoyé a été reçu avec succès par une entité d'administration quand pour celle-ci aucune autre réponse n'est définie. 4. Message ADM-ERROR-ACK :
Ce message indique à IMD qu'un message précédemment envoyé n'a pas été reçu avec succès par une unité d'administration et ne peut pas être traité à cause d'une erreur du système. Ce message indique les raisons du défaut. La réception de ce message indique par ailleurs à IMD qu'aucune action n'a été entreprise sur le message qui a provoqué cette réponse négative.
5. Message ADM-LIST-REQ :
Ce message est envoyé par le module spécifié dans le champ OBJECT- type.
Pour les objets de connexion, de sélection et IVMO, il fournit le nom des objets dont le type est spécifié dans le champ OBJECT-type et qui sont associés à l'objet de couche identifié par les champs OBJECT-uptype, OBJECT-upname, SUBSYSTEM.
6. Message ADM-LIST-ACK :
Ce message est envoyé par une entité de PILE (empilement de couches) au module IMD en réponse à son message de type 5. Il donne la liste des noms administratifs aux instances d'objet pour un type d'objet donné.
7. Message ADM-GET-REQ :
Ce message est envoyé par IMD pour demander à une entité administrée de retourner la valeur des attributs d'une instance d'objet. Si une liste d'attributs est fournie, la liste des valeurs des attributs doit être retournée au module IMD. Si aucune liste n'est fournie, toutes les valeurs d'attributs doivent être retournées. Une erreur est indiquée dans la réponse fournie par l'entité d'administration si un attribut quelconque ne peut être lu.
8. Message ADM-GET-ACK :
Ce message est envoyé par l'entité d'administration à IMD en réponse au message précédent de type 7. Il renvoie les valeurs d'attributs de l'instance d'objet requises. Une erreur est indiquée si au moins un attribut ne peut être lu. 9. Message ADM-GETNEXT-REQ :
Ce message permet à une entité d'administration d'obtenir les attributs de toutes les instances d'un objet sans connaître le nom de ces instances. Il n'est pas alors nécessaire d'envoyer un message de type 5 pour obtenir le nom de l'instance d'objet. La liste des noms d'objet est gérée dans un ordre arbitraire par l'entité, cet ordre dépendant de l'implémentation de celle-ci à l'intérieur de la couche.
10. Message ADM-GETNEXT-ACK :
Ce message est envoyé par une entité d'administration en réponse au message de type 9. Elle renvoie au module IMD la valeur des attributs d'objet demandée. Une erreur est indiquée si ces attributs ne peuvent être lus.
1 1 . Messages ADM-SET-REQ :
Ce message est envoyé par IMD à une entité d'administration sur une IM STREAM. Il permet de donner une nouvelle valeur aux attributs d'une instance d'objet. Cette opération s'applique à des attributs qui sont définis comme étant en mesure d'être écrits. Leur liste fournie, dans la partie M- DATA contient les identifiants des attributs et les valeurs associées qu'on donne aux valeurs d'attributs qui doivent être remplacées.
1 2. Messages ADM-SET-ACK :
Ce message est envoyé par une entité d'administration en réponse au message précédent de type 1 1 . Il indique si l'opération de changement de valeur des attributs requise par le message de type 1 1 a été couronné de succès ou non.
13. Messages ADM-TEST-REQ :
Ce message est envoyé aux entités d'administration par IMD. Il permet de vérifier si la valeur de plusieurs attributs d'une instance d'objet peut être simultanément modifiée pour avoir une nouvelle valeur. Les valeurs d'attributs ne sont pas modifiées par ce message.
14. Message ADM-TEST-ACK : Ce message est un message d'acquittement envoyé par une entité d'administration en réponse au message précédent de type 13.
15. Message ADM-ACTION-REQ :
Ce message est envoyé par IMD aux entités d'administration. Les fonctions de ce message dépendent du type d'action mentionné dans le champ PRIM-type.
16. Message ADM-ACTION-ACK :
Ce message est envoyé par une entité d'administration en réponse au message précédent de type 1 5 et indique le succès ou l'insuccès de cette dernière requête.
17. Message ADM-ADD-REQ :
Ce message demande à une entité d'administration de créer une nouvelle instance d'objet. Il n'est pas admis pour tous les types d'objet. Pour la création d'un objet, un certain nombre d'attributs de l'objet sont exigés et doivent être fournis dans la requête. Le nom de l'objet devant être créé est fourni par le module qui l'administrera. Ce nom est fourni dans la réponse à la requête constituée par ce message.
18. Message ADM-ADD-ACK :
Ce message est envoyé par une entité d'administration en réponse au message précédent de type 17 et il permet l'acquittement en cas de succès de la requête.
19. Message ADM-REMOVE-REQ :
Ce message demande à une entité d'administration d'enlever une instance d'objet.
20. Message ADM-REMOVE-ACK :
Ce message est envoyé par une entité d'administration en réponse au message précédent de type 19 pour acquitter le succès ou l'insuccès de la requête correspondant à ce message de type 19.
21 . Message ADM-EVENT-IND : Ce message indique au module IMD qu'un événement se déroule dans l'entité de couche. Pour le module d'administration, il n'y a pas d'acquittement lorsqu'il reçoit l'indication qu'un événement est arrivé dans la dite entité de couches.
Ainsi qu'on peut le voir sur l'annexe 1 , l'ensemble des messages de type 1 à 21 est utilisé pour le modèle de référence OSI ou ISO/DSA. L'ensemble de ces messages est également utilisé pour le modèle IPS à l'exception des messages 5 et 6.
Pour le réseau de type FDDI, on utilise également les messages de type 4 et 7 à 21 .
En ce qui concerne l'identification des objets pour le modèle de référence IPS, elle présente certains aspects particuliers par rapport à l'identification pour le modèle de référence OSI.
Le champ OBJECT-type est une classe d'objets qui est composée de paramètres. Un objet IPS est défini par son champ OBJECT-type et par une instance de cette classe. SI c'est un simple objet (mono-instance) l'identification est donnée simplement par le champ (OBJECT-type). Une instance est définie par les valeurs de paramètres de sélection. Ces derniers qui donnent une identification et une valeur sont transmis dans le bloc de messages M-DATA de la requête.
Le champ OBJECT-name contient le nombre de paramètres utilisés pour la sélection. Ainsi, si cela est nécessaire, les premières instances du bloc de messages M-DATA sont les paramètres de sélection.
Les blocs de messages M-DATA sont codés en ASN.1 .
On considère désormais les différents messages de configuration numérotés de 22 à 32 (de type 22 à 32) qui sont les suivants et qui apparaissent en annexe 2.
La présentation de l'annexe 2 est strictement identique à la présentation de l'annexe 1 .
Ces différents messages sont les suivants :
22. Message ADM-SUBSYSTEM-ID : Ce message est envoyé par le configurateur CONFD dès l'ouverture de chacun des modules du processeur de communication de la figure 2 ou par chacun des modules du système SCH de la figure 3, soit en étant véhiculé par un ADM STREAM ou par un IM STREAM. N'importe quelle entité qui veut être administrée peut prendre en compte ce message et doit savoir le comprendre.
23. Message ADM-STREAM-BIND :
Ce message est envoyé par CONFD juste après l'ouverture du Stream de commande d'un module. Ce stream est ensuite affecté par ledit module au configurateur CONFD.
24. Message ADM-STREAM-ACK :
Ce message est renvoyé par le module au configurateur si la requête du message précédent de type 23 a été acceptée.
25. Message ADM-STREAM-NACK :
Ce message est renvoyé par le module au configurateur CONFD si la requête indiqué par le message de type 23 a été refusée.
26. Message ADM-STREAM-OPEN :
Ce message est envoyé au configurateur sur un ADM STREAM par un module, pour demander une nouvelle liaison de type Stream à un autre module. C'est le cas par exemple de la création de liaison streams entre la couche C4 et la couche C3 du modèle OSI. Cette liaison est à créer de manière dynamique ainsi que les normes le prévoient.
27. Message ADM-STREAM-CLOSE :
Ce message est envoyé au configurateur CONFD par un module pour demander la déconnexion d'un module. C'est le cas par exemple, en modèle OSI, d'une couche C4 (couche dite COTP) qui demande la déconnexion d'une couche C3 (dite couche CLNP) c'est-à-dire qui demande la rupture de la liaison streams entre elles.
28. Message ADM-STREAM-ERROR : Ce message est envoyé par le configurateur CONFD au module auquel le configurateur s'est adressé si une erreur s'est produite durant l'envoi d'une requête délivrée par le message ADM-STREAM-OPEN (message de type 26).
5 29. Message M-IOCTLI-LINK :
Ce message est envoyé par le configurateur en réponse au module auquel il s'est adressé, si aucune erreur ne s'est produite durant l'envoi de la requête correspondant au message de type 26.
30. Message M-IOCTLI-UNLINK :
ιo Ce message est envoyé par le configurateur en réponse au module auquel il s'est adressé, si aucune erreur n'est survenue durant l'envoi de la requête correspondant au message ADM-STREAM-CLOSE (message de type 27).
31 . Message M-IOCACK :
15 Ce message est renvoyé par le module au configurateur après l'envoi d'une requête correspondant à l'un ou l'autre des messages définis en 29 ou 30.
32. Message M-IOCNACK :
Ce message est renvoyé par le module au configurateur après l'envoi d'une requête correspondant à l'un ou l'autre des messages de type 29 ou 30. Il 20 correspond à un acquittement négatif.
On voit, en regardant l'annexe 2, que l'ensemble des messages de configuration est valable pour un empilement de couches de type OSI. Pour un empilement de type IPS, seul le message ADM-SUBSYSTEM-ID est utilisé lors de l'initialisation du processeur de communication.
25 Le message ADM-SUBSYSTEM-ID est uniquement envoyé à IAM (module interne spécifique, servant d'interface administrative entre les couches C3 et C4 de l'empilement de type IPS, et les commandes administratives délivrées par l'antenne administrative) par le configurateur CONFD.
Ce module interne représente, par construction, l'interface administrative '30 de l'ensemble des couches du module MIPS. En ce qui concerne la configuration pour le réseau FDDI, on utilise des messages normalisés de type connus SMT.
Par ailleurs, les annexes 3, 4, 5, 6 résument ce qu'il a été dit plus haut dans la description de chacun des messages. Ainsi, pour l'annexe 3, on retrouve l'ensemble des messages de configuration qui ont été définis ci- dessus en fonction des différentes circonstances. On a symbolisé sur cette annexe par un trait vertical le configurateur CONFD situé dans la partie centrale de la figure, alors que l'entité considérée, c'est-à-dire par exemple une entité d'administration de l'une des couches C4 ou C3 de l'un des modules MOSI, MIPS, MDIWS est représentée par un trait vertical situé sur la droite de la figure. Les messages sont symbolisés par des flèches, le sens de la flèche indiquant le sens dans lequel le message est envoyé. On voit donc en lisant par exemple la partie supérieure de l'annexe 3 que pour le succès de la requête de création d'une nouvelle liaison, on utilise successivement les messages ADM-STREAM-OPEN, envoyés par l'entité à CONFD, le message M-IOCTLI-LINK envoyé par le configurateur à l'entité et enfin le message M-IOCACK envoyé par l'entité au configurateur. Il est évident que la lecture de l'annexe 3 et des autres annexes est tout à fait identique à celle qui vient d'être indiquée pour la partie supérieure de l'annexe 3.
L'annexe 4 montre l'échange de messages entre le module IMD et une quelconque entité et on y retrouve pratiquement l'ensemble de tous les messages d'administration décrits ci-dessus.
L'annexe 5 décrit les deux messages qui sont échangés entre le module IMD et une entité quelconque lorsqu'un message envoyé par IMD n'est pas accepté par l'entité de couche en raison d'une erreur empêchant le traitement correct du message.
L'annexe 6 montre l'échange de messages entre CONFD, IMD et une entité de PILE lors de la phase d'initialisation. 20
ADM
MESSAGES OSI IPS FDDI EMETTEUR RECEPTEUR
ADM-BIND-LAYER-REQ X X IMD LME
ADM-BIND-OBJ-IND X X LME IMD
ADM-OK-ACK X X LME IMD
ADM-ERROR-ACK X X X LME IMD
ADM-LIST-REQ X IMD LME
ADM-LIST-ACK X LME IMD
ADM-GET-REQ X X X IMD LME
ADM-GET-ACK X X X LME IMD
ADM-GETNEXT-REQ X X X IMD LME
ADM-GETNEXT-ACK X X X LME IMD
ADM-SET-REQ X X X IMD LME
ADM-SET-ACk X X X LME IMD
ADM-TEST-REQ X X X IMD LME
ADM-TEST-ACK X X X LME IMD
ADM-ACTION-REQ X X X IMD LME
ADM-ACTION-ACK X X X LME IMD
ADM-ADD-REQ X X X IMD LME
ADM-ADD-ACK X X X LME IMD
ADM-REMOVE-REQ X X X IMD LME
ADM-REMOVE-ACK X X X LME IMD
ADM-EVENT-IND X X X LME IMD
ANNEXE 1
CONFIG
MESSAGES OSI IPS FDDI EMETTEUR RECEPTEUR
ADM-SUBSYSTEM-ID X X CONFD LME
ADM-STREAM-BIND X CONFD LME
ADM-STREAM-ACK X LME CONFD
ADM-STREAM-NACK X LME CONFD
ADM-STREAM-OPEN X LME CONFD
ADM-STREAM-CLOSE X LME CONFD
ADM-STREAM-ERROR X CONFD LME
M-IOCTLI-LINK X CONFD LME
M-IOCTLI-UNLINK X CONFD LME
M-IOCACK X LME CONFD
M-IOCNACK X LME CONFD
ANNEXE 2
Succès de la requête de création d'une nouvelle liaison
Echec de la requête de création de nouvelle liaison
Requête de fermeture de liaison
Succès liaison
streams
Echec de liaison
streams
Figure imgf000024_0001
CONFD ENTITE
ANNEXE 3
Figure imgf000025_0001
ANNEXE 4
Figure imgf000026_0001
IMD entité de couche
ANNEXE 5
Figure imgf000026_0002
ANNEXE 6

Claims

REVENDICATIONS :
1. Système de communication (SCI, SCh ) avec un réseau (RE,...) mettant en oeuvre un code de communication (CC) appartenant à une pluralité de modèles d'interconnexion de systèmes ouverts (OSI, ISO/DSA, IPS), dont le travail est organisé par au moins un système d'exploitation (GPOS, SE-j ) associé à une pluralité d'applications et dont le but est de transmettre ou de recevoir des données nécessaires aux applications vers ou depuis le réseau, comprenant un ensemble d'administration des différentes couches formant (C4, C3, C2) le code (CC) comprenant une pluralité de modules de communication appartenant à divers modèles caractérisé en ce que cet ensemble comprend :
- un configurateur (CONFD) établissant lors de l'initialisation du système, l'empilement des différentes couches au moyen de liens entre celles-ci,
- un module d'administration (IMD) permettant l'accès à toutes informations d'ordre administratif à l'intérieur de chacune des couches du code, ces dernières comportant chacune au moins une entité d'administration (LME11 , LMEτ2, •••),
- une première interface d'administration (LMAh , LMh ) disposée entre le configurateur (CONFD) d'une part, et les différentes entités d'administration, et le module d'administration (IMD) d'autre part,
- une seconde interface d'administration (LMAI2, LMI2) disposée entre le module d'administration (IMD) et les entités d'administration des couches
Figure imgf000027_0001
2. Système de communication selon la revendication 1 , caractérisé en ce que les entités (LME-π LME 12, •••) d'administration sont disposées à l'intérieur de chaque couche pour le modèle de référence OSI, et en ce que une entité commune à toutes les couches est disposées dans la couche supérieure du modèle IPS, chaque entité organisant le travail d'administration de chacune des couches pour le modèle OSI et de l'ensemble des couches pour le modèle IPS.
3. Système selon la revendication 3, caractérisé en ce que chaque entité d'administration (LME-J I , LME12, •••) 9ère un ensemble d'objets décrits chacun par une pluralité d'attributs.
4. Système selon la revendication 1 caractérisé en ce que le module d'administration (IMD) travaille en liaison avec le système d'exploitation (GPOS, SE*] , ...) et effectue le routage de messages d'administration (ADM-BIND-LAYER-REQ, ...) vers ou depuis les entités (LME*n , ...) et les outils de maintenance et de configuration disposés à l'intérieur des couches , la première et la deuxième interface (LMAh , LMAI2, LMh , LMI2) établissant les dialogues entre le module d'administration (IMD) le configurateur (CONFD) et les différentes entités d'administration (LME1 1 ,
5. Système suivant la revendication 4, caractérisé en ce que un message comprend un premier bloc (M-PROTO) suivi d'un second bloc (M-DATA), le premier bloc comprenant une structure de données dite primitive, définissant l'échange d'informations entre les entités et le module d'administration (IMD) et le second bloc des informations définissant la signification de la primitive.
6. Système selon la revendication 3, caractérisé en ce que chaque objet d'un module comprend des objets de couche contenant chacune soit des objets de connexion, soit des objets de sélection, soit des objets IVMO définissant les valeurs initiales de chaque objet de couche.
7. Système selon la revendication 6, caractérisé en ce que chaque objet administré est identifié par 3 champs , le premier champ (SUBSYSTEM-id) définissant l'identifiant du module de communication contenant l'objet en question, le second champ (OBJECT-type) définissant le type administratif de l'objet et le troisième champ (OBJECT-name) le nom interne donné par le module de communication qui contient cet objet.
PCT/FR1994/001275 1993-11-08 1994-11-04 Systeme de communication avec un reseau incluant un ensemble d'administration Ceased WO1995013676A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP95900188A EP0728392B1 (fr) 1993-11-08 1994-11-04 Systeme de communication avec un reseau incluant un ensemble d'administration
US08/624,416 US5793958A (en) 1993-11-08 1994-11-04 Network interfacing system with modules for administrating various protocol layers for a plurality of OSI models
DE69427198T DE69427198T2 (de) 1993-11-08 1994-11-04 Kommunikationssystem mit einem ein verwaltungsmodul einschliessendem netz
JP7513623A JP2888642B2 (ja) 1993-11-08 1994-11-04 管理パッケージを含むネットワークとの通信システム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR9313282A FR2712411B1 (fr) 1993-11-08 1993-11-08 Système de communication avec un réseau incluant un ensemble d'administration.
FR93/13282 1993-11-08

Publications (1)

Publication Number Publication Date
WO1995013676A1 true WO1995013676A1 (fr) 1995-05-18

Family

ID=9452626

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR1994/001275 Ceased WO1995013676A1 (fr) 1993-11-08 1994-11-04 Systeme de communication avec un reseau incluant un ensemble d'administration

Country Status (6)

Country Link
US (1) US5793958A (fr)
EP (1) EP0728392B1 (fr)
JP (1) JP2888642B2 (fr)
DE (1) DE69427198T2 (fr)
FR (1) FR2712411B1 (fr)
WO (1) WO1995013676A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8255680B1 (en) 1997-06-26 2012-08-28 Oracle America, Inc. Layer-independent security for communication channels

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6405254B1 (en) * 1996-01-03 2002-06-11 Sterling Commerce, Inc. System and method for protocol conversion using facilities and utilities
JP3137009B2 (ja) * 1996-10-25 2001-02-19 日本電気株式会社 ネットワーク複数層管理システム
GB2332335A (en) * 1997-12-10 1999-06-16 Northern Telecom Ltd Network management system
DE19809398A1 (de) * 1998-03-05 1999-09-09 Sel Verteidigungssysteme Gmbh Verfahren zum gemeinsamen Betreiben einer Vielzahl militärischer Führungssysteme, sowie ein System zur Durchführung dieses Verfahrens und eine Nutzerschnittstelle hierfür
US6976080B1 (en) * 1998-03-27 2005-12-13 Hewlett-Packard Development Company, L.P. Multiple-protocol communication subsystem controller
US6772413B2 (en) 1999-12-21 2004-08-03 Datapower Technology, Inc. Method and apparatus of data exchange using runtime code generator and translator
US6996510B1 (en) * 2000-01-21 2006-02-07 Metasolv Software, Inc. System and method for modeling communication networks
US7260635B2 (en) * 2000-03-21 2007-08-21 Centrisoft Corporation Software, systems and methods for managing a distributed network
US6671724B1 (en) 2000-03-21 2003-12-30 Centrisoft Corporation Software, systems and methods for managing a distributed network
US7738688B2 (en) * 2000-05-03 2010-06-15 Aperio Technologies, Inc. System and method for viewing virtual slides
US20020143969A1 (en) * 2001-03-30 2002-10-03 Dietmar Loy System with multiple network protocol support
US8644706B2 (en) 2010-01-22 2014-02-04 Gainspeed, Inc. Distributed cable modem termination system with software reconfigurable MAC and PHY capability
US8311412B2 (en) * 2010-01-22 2012-11-13 Selim Shlomo Rakib Distributed cable modem termination system
US9887855B2 (en) 2010-01-22 2018-02-06 Alcatel-Lucent Usa, Inc. Virtual converged cable access platforms for HFC cable networks
US8935739B1 (en) 2010-01-22 2015-01-13 Gainespeed, Inc. Distributed CCAP cable modem termination system
US9584869B2 (en) 2010-01-22 2017-02-28 Gainspeed, Inc. Virtual CCAP cable modem termination system with software reconfigurable MAC
CN102845024B (zh) * 2011-03-19 2015-06-17 加速有限公司 分布式电缆调制解调器终端系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0463764A2 (fr) * 1990-06-28 1992-01-02 Digital Equipment Corporation Système et procédé de gestion d'ordinateur avec un agent commun

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5613100A (en) * 1989-09-12 1997-03-18 Nec Corporation Computer system having an open systems interconnection (OSI) management system for an information conversion for management of non-open systems
US5317568A (en) * 1991-04-11 1994-05-31 Galileo International Partnership Method and apparatus for managing and facilitating communications in a distributed hetergeneous network
US5491822A (en) * 1993-12-30 1996-02-13 International Business Machines Corporation Multi-phase commit processing for creation and deletion of managed objects

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0463764A2 (fr) * 1990-06-28 1992-01-02 Digital Equipment Corporation Système et procédé de gestion d'ordinateur avec un agent commun

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
S.M.KLERER: "THE OSI MANAGEMENT ARCHITECTURE: AN OVERVIEW", IEEE NETWORK: THE MAGAZINE OF COMPUTER COMMUNICATIONS., vol. 2, no. 2, March 1988 (1988-03-01), NEW YORK US, pages 20 - 29 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8255680B1 (en) 1997-06-26 2012-08-28 Oracle America, Inc. Layer-independent security for communication channels

Also Published As

Publication number Publication date
FR2712411B1 (fr) 1995-12-22
FR2712411A1 (fr) 1995-05-19
DE69427198D1 (de) 2001-06-13
EP0728392B1 (fr) 2001-05-09
JP2888642B2 (ja) 1999-05-10
EP0728392A1 (fr) 1996-08-28
JPH09500750A (ja) 1997-01-21
DE69427198T2 (de) 2001-08-23
US5793958A (en) 1998-08-11

Similar Documents

Publication Publication Date Title
EP0728392B1 (fr) Systeme de communication avec un reseau incluant un ensemble d&#39;administration
EP0349371B1 (fr) Système informatique à interconnexion centrale
EP0479096B1 (fr) Pont pour relier un réseau local, conforme à la norme ieee 802.3 à un réseau de télécommunications à technique temporelle asynchrone
US6810431B1 (en) Distributed transport communications manager with messaging subsystem for high-speed communications between heterogeneous computer systems
EP0661857A1 (fr) Procédé de conversion automiatique d&#39;applications de télécommunication
EP0599706A2 (fr) Dispositif de traitement de l&#39;information permettant la gestion d&#39;une ressource informatique par un système d&#39;administration
FR2773935A1 (fr) Procedes de communication entre systemes informatiques et dispositifs les mettant en oeuvre
FR2670925A1 (fr) Architecture informatique distribuee utilisant un reseau local de type csma/cd.
CA2089864A1 (fr) Systeme de relais de transport osi entre un reseau en mode connecte et un reseau en mode non connecte
EP0182678A1 (fr) Terminal de télé-informatique à extensions externes
EP0676881B1 (fr) Vérification d&#39;intégrité de données échangées entre deux stations de réseau de télécommunications
EP1304836A1 (fr) Bus de terrain déterministe et procédé de gestion d&#39;un tel bus
EP0615370B1 (fr) Système de communication avec un réseau
EP0537040B1 (fr) Système de test d&#39;un réseau en forme d&#39;anneau à trés haut débit et procédé de mise en oeuvre de ce système
BE1003811A3 (fr) Systeme de test integre pour test de conformite de systemes de communication.
EP1511217A1 (fr) Utilisation d&#39;un système de gestion d&#39;équipements de réseau à base de règles de politique, pour le controle centralisé de l&#39;instauration de règles de politique
Jasud The OSI model: Overview on the seven layers of computer networks
CH632350A5 (en) Data processing assembly
EP0470875B1 (fr) Contrôleur de communication entre un ordinateur et une pluralité de terminaux de type RNIS
FR2843847A1 (fr) Systeme permettant d&#39;etablir une connexion telnet avec un dispositif eloigne depourvu de modem
FR2708116A1 (fr) Système de communication avec un réseau et protocole d&#39;accès aux fournisseurs de transports appartenant à ce système.
EP0454558A1 (fr) Convertisseur multiprotocoles de raccordement d&#39;une pluralité de terminaux asynchrones à un réseau de télécommunications
FR2867641A1 (fr) Systeme de memorisation a tolerance de pannes a architecture d&#39;interconnexion qui assure egalement le trafic du reseau
EP1370045B1 (fr) Système d&#39;accès à des données disponibles sur réseau actif
EP0599681A1 (fr) Outil de simulation d&#39;un code de réseau

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): JP US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IE IT LU MC NL PT SE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 1995900188

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 08624416

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 1995900188

Country of ref document: EP

WWG Wipo information: grant in national office

Ref document number: 1995900188

Country of ref document: EP