JP4818186B2 - Network system, resource allocation method, and resource allocation program - Google Patents

Description

  The present invention relates to a network system, a resource allocation method, and a resource allocation program that can efficiently allocate network resources.

  There is a method called COPS (Common Open Policy Service) as a protocol for controlling a quality of service (QoS) policy of a network (Non-Patent Documents 1 to 3). This is to instruct a policy (for example, what QoS is to be set) from the centralized management server to the router or the like as necessary, and distributes information on the policy (operation policy) of the network system to the router. This is a protocol for configuring routers. This makes it possible to perform network policy control.

  The PIB (Policy Information Base) is a database of policy information expressed in a format similar to the MIB (Management Information Base) defined for management of network devices. COPS is a client-server type database distribution protocol that notifies policy information managed by the PIB. There are two types of COPS, the open source method and the provision method. The former sends a request from a node called PEP (Policy Enforcement Point) such as a router to a node called PDP (Policy Decision Point: COPS server) and responds to it. The latter method is a method of notifying the policy in the form, and the latter is a method in which the PDP makes an independent determination and unilaterally notifies the policy to the PEP.

  Further, as a method of COPS, there is a method called COPS-RSVP combined with RSVP (Resource Reservation Protocol). As shown in FIG. 10, the COPS-compatible router (FIGS. 10 (1), (4), (7)) that received the RSVP signal makes an inquiry to the COPS server every time whether it is possible to allocate resources. (FIGS. 10 (2) and (5)), it is determined how much resources the COPS server allocates and issues instructions to the router (FIGS. 10 (3) and (6)).

This COPS-RSVP performs or tries to allocate resources according to the RSVP signal, but does not know at all why the resource needs to be allocated. In other words, it does not know whether resource allocation is actually requested in order to use the application. On the other hand, Non-Patent Documents 4 and 5 propose a method for allocating resources for each session (exchange with an application). In this method, as shown in FIG. 11, when a client accesses the application server, the application server requests resource allocation from the COPS server and receives the result as a token. The token is returned from the application server to the client. Thereafter, the client issues a resource allocation request to the network (for example, using RSVP), and adds a token to the message (FIGS. 11 (1) to (4)). After that, as in COPS-RSVP, each router issues a resource allocation request with a token to the COPS server, and the COPS server responds with a resource to be allocated according to the situation (FIGS. 11 (5) to (8)).
http://www.ietf.org/rfc/rfc2748.txt http://www.ietf.org/rfc/rfc2749.txt http://www.ietf.org/rfc/rfc4261.txt http://www.ietf.org/rfc/rfc3520.txt http://www.ietf.org/rfc/rfc3521.txt

  However, in the conventional system, an inquiry / response to the COPS server is required for each router. Under the premise that the COPS server monitors and grasps the status of the network one by one, it is excellent in terms of allocating resources according to the situation at that time as much as possible, but finally classification is performed like Diffserv. In the case of a service such as that, there is a high possibility that such fine control does not make sense. In addition, an update procedure or the like is necessary to maintain the allocated resources, but the COPS server must maintain and manage all information such as “the resource must be maintained from when to when” for each session. In addition, each time the signaling for the update procedure is performed, the same processing as that for resource allocation is performed, which causes a problem that the load on the COPS server becomes very large.

  Diffserv is one of the mechanisms for providing QoS in the network, and is a technique for classifying traffic into classes and applying QoS for each class. Actually, the classification at the edge router (determination of the TOS field of the IP header, the Traffic Class field value of IPv6, etc.) and the control of the bandwidth limit etc. are performed at each router based on these values.

  The present invention has been made in view of such circumstances, and a network system and resource that can delegate authority to an end node such as a client or an application server and suppress the load of a resource allocation management server such as a COPS server. An object is to provide an allocation method and a resource allocation program.

  The present invention is a network system including a resource management server that performs QoS setting for the router in order to perform information communication between the originating device and the terminating device via the router, Means for receiving a response to the QoS generation request sent by the called device to the resource management server; and means for sending a token including QoS setting information from the called device to the calling device; Means for setting the QoS of the router based on the QoS setting information included in the token.

  In the present invention, the router sets QoS based on the QoS setting information when the destination address of the token is the originating device and the transmission source address of the token is the terminating device. It is characterized by.

  According to the present invention, the token has a lifetime, and the QoS lifetime of the router can be updated without transmitting the QoS generation request to the resource management server during the token lifetime period. It is characterized by being.

  The present invention is characterized in that the router sets QoS based on the QoS setting information when the validity of the token is confirmed.

  The present invention is characterized in that the information in the token is encrypted using a different encryption key each time information communication is performed between the transmission side device and the reception side device.

  The present invention relates to a resource allocation method in a network system including a resource management server for setting QoS for a router in order to perform information communication between the originating device and the terminating device via the router. A step of receiving a response to the QoS generation request transmitted from the receiving device to the resource management server, and transmitting a token including QoS setting information from the receiving device to the calling device. And setting the QoS of the router based on the QoS setting information included in the token.

  The present invention operates on a network system provided with a resource management server for setting QoS for the router in order to perform information communication between the originating device and the terminating device via the router. A resource allocation program, comprising: a process for receiving a response to a QoS generation request transmitted from the callee apparatus to the resource management server; and QoS setting information from the callee apparatus to the caller apparatus A process for transmitting a token and a process for setting the QoS of the router based on the QoS setting information included in the token are performed by the computer.

  According to the present invention, the process of setting the QoS of the router is based on the QoS setting information when the destination address of the token is the transmitting side device and the transmission source address of the token is the receiving side device. , Qos is set.

  According to the present invention, the token has a lifetime, and the QoS lifetime of the router can be updated without transmitting the QoS generation request to the resource management server during the token lifetime period. It is characterized by being.

  The present invention is characterized in that the process of setting the QoS of the router sets the QoS based on the QoS setting information when the validity of the token is confirmed.

  The present invention is characterized in that the information in the token is encrypted using a different encryption key each time information communication is performed between the transmission side device and the reception side device.

  According to the present invention, since the maintenance (lifetime update) processing of QoS set in the router can be distributed by using the token, the central server does not need to manage all, and the entire network system The effect that the efficiency of this can be improved is acquired. In addition, by introducing a direction in which QoS setting can be performed, an illegal resource allocation request can be prevented. In addition, with respect to P2P communication using SIP, there is an effect that QoS between SIP clients can be managed similarly.

  Hereinafter, a resource allocation method according to an embodiment of the present invention will be described with reference to the drawings. FIG. 1 is a diagram showing a configuration of a network system according to the embodiment. As shown in FIG. 1, the network system includes at least a user terminal (End-Host) 1, an application server (hereinafter referred to as APPS) 2, and a resource management server (Resource management Server) 3. For example, APPS 2 is a video distribution server. In this configuration, EH1 is the client. In the case of communication between clients using SIP, a caller's SIP client (User Agent Client, UAC) 4, a callee SIP client (User Agent Server, hereinafter referred to as UAS) 5, a SIP server 61. , 62. The network according to the present invention is a Diffserv-compatible core network and includes edge routers 71 to 76 and 8. However, the edge router 8 does not necessarily need to use Diffserv. In the present invention, QoS is set for the edge routers 71 to 76. That is, by setting a DSCP (Differentiated Services Code Point) value for a packet going from a certain source to a certain destination, the packet is preferentially forwarded in the network according to the DSCP value. It is.

  NSIS or the like has been proposed as signaling for controlling QoS, but the present invention is not particularly limited thereto. Here, it will be explained what messages need to be exchanged by focusing on the essential elements, but these contents can be handled as one element of signaling such as existing NSIS. NSIS (Next Step In Signaling) is a method developed and generalized by RSVP, which is a protocol that reserves a bandwidth to a transmission destination on a network and ensures communication quality. A signaling layer (NSLP: NSIS Signaling Layer Protocol) that implements various signaling and a transport layer (NTLP: Nsis Transport Layer Protocol) that provides a mechanism for transferring signaling between NSIS entities (such as routers that support NSIS) ). Various schemes can be implemented as NSLP. For example, it is possible to perform the same function as RSVP, or to perform control for Diffserv control.

  Next, a service model assumed in the present invention will be described. The service model here means that a network provider provides a service that guarantees a certain bandwidth to an application service provider. For example, it guarantees the bandwidth to the service provider that distributes the video, and the service user has to allocate the bandwidth required for receiving the video individually, and enjoy the video without being affected by other application traffic Is to be able to.

  However, since the bandwidth allocated to the entire video distribution service is limited, the provider of the video distribution service is a resource managed by the network operator so that the authority regarding the setting of the QoS itself is managed so as to avoid waste of bandwidth allocation to the user as much as possible. Although the management server 3 performs it, the authority (the authority regarding the lifetime update of QoS setting) is delegated to the application provider and the user regarding how to maintain this. Further, it is assumed that the application provider leads QoS maintenance management on the assumption that the user is not always reliable because the application provider pays the network QoS.

  On the other hand, for P2P communication such as IP phone using SIP, not only UAC (caller) 4 but also UAS (caller) 5 is a general user, so the service model is not exactly the same. In the case of communication using SIP, the SIP servers 61 and 62 mediate authority delegation to the UAC4-UAS5, so that QoS can be maintained only between the UAC4-UAS5.

  Next, information sharing with the resource management server 3 (RS) will be described. The resource management server 3 knows to which user the received signaling packet is related, and confirms the validity of the information by “ID information” and “shared secret key (user key) information” with each user client. "Must be shared. Here, the ID information allows the resource management server 3 to uniquely identify the user client, and is, for example, a URI, an IP address, a certificate, or the like. The shared secret key information is for encrypting secret information (temporary key described later) from the user, and confirms whether it can be decrypted to confirm whether it is a signal from the correct user. Is.

  Next, the functional configuration of the resource management server 3 will be described with reference to FIG. The resource management server 3 includes a user information management unit 31 that manages user information, a signaling processing unit 32 that performs signaling processing with the outside, and a QoS management unit 33 that performs resource allocation. These can be used in various existing methods. Further, the user information management unit 31 may exist in a node (for example, an authentication server) different from the resource management server 3.

  Next, the signaling type (token) processed by the signaling processing unit 32 will be described. In the present invention, the edge routers 71 to 76 perform resource allocation based on the token issued by the resource management server 3. In the following description, a “sender” is a node that triggers the start of a session, for example, the user terminal 1 or the UAC4, and a “caller” is a node that accepts a session start, for example, APPS2 or UAS5.

(1) INITIAL token This token is sent from a caller to a callee (or SIP server) at the start of a session.
(2) AUTHENTICATED token When this is returned from the called party, the router on the route sets the QoS. Note that QoS is set in both directions.
(3) REFRESH token A request for updating the QoS lifetime sent from the caller to the callee (or SIP server).
(4) REQUEST token In the case of P2P communication by SIP, this token is first sent from the UAC 4 to the UAS 5 and is sent next to the AUTHENTICED token received from the SIP servers 61 and 62.
(5) ACCEPTED token In the case of P2P communication by SIP, the REFRESH or REQUEST token sent from UAC4 to UAS5 is sent from UAS5 to UAC4 and functions in the same manner as the AUTHENTICATED token.
(6) TENTATIVE token This is a token for notifying that a new session is scheduled to be started, and is notified from the SIP servers 61 and 62 to the UAS 5.

  Note that the QoS setting for “bidirectional” means that bandwidth allocation is performed for both the direction from the caller to the callee and the direction from the callee to the caller. The AUTHENTICATED token and the ACCEPTED token can be sent only from the called party. Also, as far as the same session is concerned, use one token and change and use only the necessary parts. That is, in order to send the next token, the previously received token must be retained.

  Next, the security of the token will be described. Although various information is included in the token, only the AUTHENTICATED token and the ACCEPTED token contain information (QoS control information) that is directly used by the edge router to set QoS in the elements constituting the token. It is. QoS control information may be included in other tokens, but QoS control information is meaningless information in other tokens. This QoS control information can be created only by the resource management server 3, and each router and APPS 2 are only allowed to browse. This prevents unauthorized resource allocation. Further, the resource allocation is led by the callee (the same applies to RSVP and the like), which means that resource allocation is not performed unless the callee responds to a request from the caller. Also, resource reservation and update are performed by sending an INITIAL token and a REFRESH token from the caller, and returning an AUTHENTICATED token and an ACCEPTED token by the callee accordingly. Furthermore, there is also a mechanism in which the receiving side verifies the token from the calling side and does not respond to an illegal token.

  That is, in order to ensure safety, “the user / application server cannot falsely perform QoS assignment of the router”, “the application server leads the update (time extension) of QoS assignment”, It is made to satisfy the point that “it works effectively only for the correct communication pair (server and client)”.

Next, an encryption key necessary for the token will be described. Six types of encryption keys are required in total, and further classified into those using the shared secret key method and the public key encryption method.
<Public key encryption>
・ Kqs, Kqp: For QoS control protection (prevents tampering)
The private key is basically held only by the resource management server 3, and the public key is held by the router and APPS2.
・ Kas, Kap: For protection of authentication information by issuing agencies (preventing tampering)
The private key is held only by the resource management server 3, and the public key is held by APPS2.
Kuas, Kuap: For creating an authenticator (digital signature) when using a SIP application UAC4 creates a pair, and UAC4 and UAS5 share the pair. The public key Kuap is placed on the QoS management unit 33.

<Shared secret key encryption>
Ku: user key The resource management server 3 and the user terminal 1 share in advance. There is a different Ku for each user.
Kt: User information concealment and token protection (authenticator calculation) Created for each session. Further, the APPS 2 and the user terminal 1 (or the UAC 4 and the UAS 5 or the SIP proxy) are shared.
Kapp: Application server key Used by APPS2 to store information in a token. Further, it is held by APPS2 alone.

  Next, the configuration of the token will be described. FIG. 3 shows the configuration of the token. As shown in FIG. 3, the tokens are “session information part (Session)”, “QoS control part”, “issuing body information part”, “server information part”, “user information part”, “time stamp / authenticator part”. Consists of. The information contained in each is as follows.

<Session information section>
The session information section is information for identifying which session the information is related to. When the APPS 2 (or SIP server) and the resource management server 3 that have received the token for the first time decrypt the user information of the INITIAL token, the shared key It is information for specifying However, this information becomes unnecessary when it can be replaced with other elements of the NSIS message, for example. The session information part is based on the source address, destination address, destination port, source port, and user ID (when the IP address that uniquely identifies the node is not registered in the user information management part of the resource management server 3). Constitute.

<QoS control unit>
The QoS control unit is information used by the edge router to set QoS, and is created by the resource management server 3 and encrypted with Kqs. The QoS control unit further includes a session information group, a QoS lifetime, a token lifetime, and a public key Kuap. The session information group includes information on the called party (such as APPS2), information on the calling party (user), DSCP value, and a flag indicating whether the communication is between the client server and the P2P communication. The QoS lifetime is a period during which the edge router maintains its QoS setting (for example, 1 minute), that is, a period during which the edge router sets QoS with a single AUTHENTICED / ACCEPTED token. The token lifetime is equivalent to the token lifetime of the issuing institution information (the issue period information cannot be referred to by the router, so a copy is placed here). The public key Kuap is used by the edge router for verification of tokens in the case of P2P communication using SIP, and is unnecessary when SIP is not used.

  Since the AUTHENTICATED token and ACCEPTED token describe the sender information and the called party information in this session information, the router checks the source address and destination address of the packet and compares it with this session information, so that QoS can be calculated. It is possible to determine whether or not to set. For example, if the source and destination are reversed, the packet is ignored if it does not match. Note that the session information group allows a plurality of session information to be held, and a plurality of paths can be controlled with one token. In addition, QoS setting is not performed for an address unrelated to the edge router that received the token, and the portion is ignored. Further, when it is desired to change the lifetime set for each session, the QoS lifetime may be incorporated in the session information section.

<Issuing agency information department>
The issuing organization information section is information related to the resource management server 3 and the user, created by the resource management server 3 and encrypted with Kas. Issuing institution information includes the user ID (for example, host name, URI, IP address, etc.) of the issued resource management server 3, issuance time, and token lifetime (expiration date of the token itself. The received router and APPS2 discard the token or return an error), and user information (for example, a user ID such as a host name and URI, and a user IP address). The user ID must be such that the resource management server 3 can uniquely identify the user. FQDN (fully qualified domain name) or URI is desirable.

<Server information section>
The server information part is information used by APPS2, and is encrypted with Kapp. The server information stores a sequence number that should be included in the next received token to prevent a token retransmission attack, and transmits it to the caller (EH). When receiving, it confirms whether this sequence is used or not. It consists of a sequence number for Server information has a role to reduce information for each session to be managed by the server, and also has a role to improve resistance to packet loss. Since Kapp is held only by the APPS 2, any APPS 2 dependent information can be stored.

<User information section (AUTHENTICATED token)>
The AUTHENTICATED token is information for exchanging information between the caller, the callee, and the resource management server 3, and is basically encrypted with the temporary key Kt generated by the user. An AUTHENTICATED token in the direction from the callee to the caller is always encrypted with Kt. The INITIAL token is encrypted with Ku.

  Information to the caller is encrypted with Kt, and consists of QoS lifetime, token lifetime, sequence number, session information, and time difference. The QoS lifetime is the same as the QoS lifetime of the session information group. The token lifetime is equivalent to the token lifetime of the issuing institution information. The sequence number is the same as the next sequence in the server information section. The user sees this and forms a token using this value for the next REFRESH token. When SIP is used, it is necessary to separately perform REFRESH to the SIP server and REFRESH to the UAS, so that the sequence number of the AUTHENTICATED token needs to be held in the UAC. The session information is the same as the session information in the QoS control information section (since the QoS control section cannot decipher EH). The time difference is determined by using the time difference as the difference from the time when the callee sent, so that the time difference from the callee can be understood, so that the time difference is transmitted to the sender. When the sender sends the token next time, the sender can add the value to a time stamp described later, so that the time reference can be roughly combined.

  The SIP information is information referred to by the UAS 5, encrypted with the Ku of the UAS 5, QoS lifetime, token lifetime, sequence number, session information, Kt of this session (created by UAC), public key pair Consists of Kuas. The QoS lifetime, token lifetime, sequence number, and session information are the same as the information for the caller. If it is desired to change the lifetime set for each session, the QoS lifetime may be incorporated in the session information section. The SIP information is for giving information about a session between UAC4 and UAS5 described later, and is a REFRESH token that is stored in the AUTHENTICATED token from the SIP server to UAC4 and transferred from UAC4 to UAS5 as it is. . Since this is encrypted with the user key Ku of the UAS 5, the encryption can be released only with the UAS 5.

<User information part (ACCEPTED token)>
The ACCEPTED token is information for exchanging information in a token sent from UAS 5 (the called party) to UAC 1 (the calling party) when using SIP, and is encrypted with the key Kt transmitted from UAC 4.

  Information to the caller is encrypted with the key Kt, and is composed of QoS lifetime, token lifetime, sequence number, session information, and time difference. The QoS lifetime is the same as the QoS lifetime of the session information group. The token lifetime is equivalent to the token lifetime of the issuing institution information. The sequence number has the same value as the next sequence of SIP information, and UAC 4 sees this and uses this value to form a token for the next REFRESH token. The session information is the same as the session information in the QoS control information section (since the QoS control section cannot decipher EH). The time difference is determined by using the time difference as the difference from the time when the callee sent, so that the time difference from the callee can be understood, so that the time difference is transmitted to the sender. When the sender sends the token next time, the sender can add the value to a time stamp described later, so that the time reference can be roughly combined.

  The SIP information is information referred to by the UAS 5, is encrypted with the key Ku of the UAS 5, and is composed of a scrambled (because the same data is loaded, the result of the encryption is the same value) and a time stamp and the next sequence number. . Note that when information such as QoS lifetime and token lifetime is illegally rewritten, it can be detected by the router, and therefore a discard or error is returned.

<User information section (INITIAL token)>
The INITIAL token is encrypted with the user key Ku instead of the key Kt. It is composed of a time stamp, a user ID, a temporary key Kt generated by the user, and a public key pair Kuas, Kuap. The public key pair Kuas, Kuap is information to be placed only during SIP communication, and the keys Kuas, Kuap are preferably generated for each session.

<User information part (REFRESH token)>
The REFRESH token is composed of a sequence number for storing a sequence number from APPS (or UAS) received immediately before and SIP information. The SIP information is stored as it is even when the ACCEPTED token received from the UAS 5 includes the SIP information. Since this information is encrypted with the key Ku of UAS 5, UAC 4 cannot be decrypted. When UAS 5 receives SIP information, it decrypts it and compares the sequence number in the SIP information with the sequence information (sequence number) outside the SIP information, which is the same as the defense against retransmission attack in APPS2. It becomes possible. In addition, when it is not a SIP application (that is, when communicating with APPS), SIP information is not added.

<User information part (REQUEST token)>
The REQUEST token is composed of a sequence number (because it has no particular meaning, it becomes 0) and SIP information. If the SIP information is included in the user information part of the AUTHENTICATED token received by the UAC 4 from the SIP server, the SIP information is stored as it is in the REQUEST token transmitted to the UAS 5 immediately after that. Since this information is encrypted with the key Ku of UAS 5, UAC 4 cannot be decrypted.

<Time stamp / Authentication part>
The time stamp / authenticator part is information for verifying whether the token is valid. The legitimacy here is a token that is exchanged between correct end nodes. In the client / server model, since the user terminal 1 and APPS 2 hold a common key Kt, a message authenticator such as HMAC-MD5 (keyed hash function) of the entire token is added using this key. In the case of a token between UAC4 and UAS5, UAC4 and UAS5 add a digital signature using a secret key Kuas exchanged with SIP information. The validity is determined by calculating the digital signature and obtaining the same value. The intermediate edge router verifies the digital signature using the key Kuap stored in the QoS control information, and if it is correct, sets the QoS (updates the lifetime), and if not correct, discards it or returns an error. . The time stamp is used to defend against replay attacks, and is written taking into account the time difference. Tokens that come from a past time for a certain time or more are discarded on the receiving side. The authenticator is composed of a message authenticator such as HMAC-MD5 or a digital signature.

  Next, session information will be described. User terminal 1 (same for UAC and UAS) and APPS2 (SIP server is also handled in the same way as APPS) each manage a session and perform QoS refresh with a token for each. The management server 3 does not necessarily have to manage a session. However, if the QoS management unit 33 needs the QoS allocation, it needs to be managed. Constituent elements of the session information entry include the own IP address, own port number, partner IP address, port number, user ID, temporary key Kt, sequence number (values included in the token received last time from the incoming side) Yes), QoS lifetime, token lifetime, time difference (valid only for user terminal 1 and UAC4), public key pair Kuas, Kuap (necessary when using SIP), server information part (for token from SIP server) Only the server information part is saved) and related session information (necessary when using SIP). However, as for the related session information, the UAC 4 must associate the session with the SIP server and the session with the UAS 5.

  Next, a processing operation at the start of a session in a client / server model in which the user terminal 1 communicates with the APPS 2 will be described with reference to FIG. First, when the user terminal 1 and APPS 2 start communication, the user terminal 1 sends an INITIAL token to the APPS 2 and transmits a temporary key Kt and a user ID (step S1). At that time, a session information entry is also established on the user terminal 1, and the received APPS 2 similarly establishes a session information entry. This is management information for performing QoS control regarding this session. The user ID included in the Session part of the INITIAL token is composed of information such as an IP address and a URI. Also, the temporary key Kt (and time stamp etc.) included in the user information part is encrypted with Ku. Further, APPS2 associates this INITIAL token with the session and holds it for a while for later processing. Here, the transmission timing of the INITIAL token is after the start of data communication, but this may be reversed. What is important is that the INITIAL token arrives at APPS2 before the authentication procedure performed at the application level is completed.

  Next, APPS2 performs user authentication with an application as usual (step S2). The authentication method performed here depends on the application. If the authentication is successful, the APPS 2 sends a QoS generation request to the resource management server 3 (step S3). At this time, APPS2 delivers the contents of the INITIAL token held therein as it is.

  Next, the resource management server 3 acquires a user key based on the user ID of the Session part in the token, and decrypts the user information part to obtain a temporary key Kt. Then, the resource management server 3 inquires of the QoS management unit 33 about the QoS to be assigned to the user, generates QoS control information and issuing institution information included in the token, and other portions may be dummy information. The session information group of the QoS control information section is for one session, the incoming side is APPS2, and the outgoing side is user terminal 1. Subsequently, the resource management server 3 transmits a token response by transmitting the created token and the temporary key Kt to the APPS 2 (step S4). Thereby, APPS2 completes the session information entry.

  Next, APPS2 generates a server information part, a user information part, and a time stamp / authenticator part in the received token, and transmits them to the user terminal 1 as an AUTHENTICATED token (step S5). The user information part includes the session information extracted from the QoS control part of the token and the sequence number to be received next time (the same value as the next server information part) and is encrypted with the acquired temporary key Kt. The QoS control unit can be decrypted because APPS2 has the public key Kap. The server information unit encrypts the sequence number to be received next time and other necessary information with the APPS2 unique key Kapp. The authenticator is a keyed hash using the temporary key Kt (for example, HMAC-MD5), the calculation range is the whole token, and the authenticator part is 0.

  Next, the edge router between APPS 2 and user terminal 1 checks the QoS control part of the AUTHENTICATED token, and performs QoS setting (Diffserv) for this session. The contents to be checked here are that the QoS control unit can correctly decrypt with the public key Kqp, that the token lifetime has not expired, the destination address of the IP header of the received token is the session information sender, and the transmission of the IP header The original address is the incoming side of the session information, that is, the directionality is AUTHENTICATED from the incoming side.

  Next, the user terminal 1 that has received the AUTHENTICATED token searches the session information entry based on the Session part, decrypts the user information part of the received token with the temporary key Kt, and completes the session information entry. At the same time, timer management for refreshing is started. Also, the difference between the time stamp of the received token and the time of the user terminal 1 itself is calculated, and the value is stored in the time difference of the session information entry. This time difference is used when the REFRESH token is transmitted next time.

  When each edge router sets Diffserv, the lifetime is set for each session, and the entry is deleted when the period expires. The lifetime is the QoS lifetime of the QoS control unit of the token. Before the lifetime expires, it is necessary to update (refresh) the lifetime with the next AUTHENTICATED token. Also, if the time stamp of the received token is large and deviated from the current time (for example, 10 seconds or more), the token is discarded to prevent a replay attack.

  Next, with reference to FIG. 5, the operation for maintaining the QoS during the session will be described. The QoS lifetime related to each session is monitored at the user terminal 1 (calling side), and a REFRESH token is transmitted to the APPS 2 when about half the time limit has elapsed (step S11). At this time, the sequence number of the session information entry is stored in the user information part and encrypted with the temporary key Kt, the time is adjusted by the time difference of the session information entry, the time stamp is stored in the REFRESH token, and the temporary key Kt is stored. To calculate the authenticator.

  Next, APPS2 obtains the sequence number by decrypting the server information part of the received token, searches the temporary key Kt based on the Session part, and decrypts the user information to match the sequence number in it. Check whether or not. Further, the authenticator is calculated and verified using the temporary key Kt. Further, it is checked whether or not the token lifetime of the QoS control unit or the issuing organization information unit has expired. If the token lifetime has expired, the token is discarded, and the corresponding session information entry is also discarded. If the remaining token lifetime has been reduced to about half of the time limit, APPS 2 sends a QoS generation request to resource management server 3 again (step S12) and receives a token response (step S13).

  If there is no particular problem as a result of the previous check, or if a token response is received from the resource management server 3, the APPS 2 is updated by randomly determining the sequence number, and the server information part, user information part (Same value), each encrypted with an encryption key, and an AUTHENTICATED token is transmitted to the user terminal 1 (step S14). The edge router between the APPS 2 and the user terminal 1 checks the QoS control unit of the AUTHENTICATED token and sets the QoS (update of lifetime) for the session. Also, the user terminal 1 that has received the REFRESH token updates the session information entry, updates the timer for refreshing, calculates the difference between the time stamp of the received token and the time of the user terminal 1 itself, Store the value in the time difference of the session information entry. This time difference is used when the REFRESH token is transmitted next time. If there is no session corresponding to the node that has received the REFRESH token or the AUTHENTICATED token, the token is ignored.

  Next, referring to FIGS. 6 and 7, after the UAC 4 establishes a session with the UAS 5 via the SIP servers 61 and 62, when the session starts in the P2P model using the SIP in which the UAC 4 and the UAS 5 communicate directly. The operation will be described. Here, it is assumed that the SIP servers 61 and 62 can be regarded as a client server model server and the UAC 4 can be regarded as a client.

  First, after SIP INVITE, the UAC 4 transmits an INITIAL token to the SIP server 62 (step S21). This INITIAL token includes a public key pair Kuas, Kuap. In response to this, the SIP server 62 creates a session information entry by receiving the INITIAL token. At this time, only the address, port number, and user ID of the UAC 4 and the SIP server 62 are registered in the entry. Other than these are encrypted and cannot be decrypted. Furthermore, the INITIAL token is linked to the session and held for a while for later processing. If subsequent SIP authentication fails, the session entry is deleted, and processing related to the following token is not performed.

  Next, when the SIP INVITE message reaches the nearest SIP server 61 of the UAS 5, the SIP server 61 transmits a TENTAIVE token to the UAS 5 (step S22). Here, the notified information is the IP address and port number (for SIP signal) of the SIP server 61, and the IP address and port number of the UAC4. At this time, if a predetermined procedure does not occur after a certain period of time, this entry is deleted.

  Next, the UAS 5 that has received the TENTATIVE token recognizes only that a future session is likely to be made, creates a session information entry, and stores the address and port number of the SIP server 61 as related session information. Subsequently, the SIP server 61 transmits SIP INVITE to the UAS 5 (step S23). The session information entry created by the TENTAIVE token allows the UAS 5 to recognize that the session related to the SIP signaling is an existing session. That is, since the IP address, port number, and related session information match the SIP INVITE information, it can be recognized as an existing session. At this point, the UAS 5 does not perform any processing related to the token.

  Next, the UAS 5 returns “SIP 200 / OK” via the SIP servers 62 and 61 (steps S24 and S25). When the nearest SIP server 62 of UAC4 receives “SIP 200 / OK”, the media information of UAC4 and UAS5 (IP address and port number used for direct data communication between UAC4 and UAS5) and the user ID of UAS5 are obtained. I can know. The UAS 5 information is registered in the related session information of the session information entry of the SIP server.

  Next, the INITIAL token obtained in the SIP server 62, the media information of the UAC4 and UAS5, and the user ID are transmitted to the resource management server 3 as a QoS generation request (step S26). In response to this, the resource management server 3 acquires the user key based on the user ID of the Session part in the token, decrypts the user information part, and obtains the temporary key Kt of the UAC4. Subsequently, the resource management server 3 inquires the QoS management unit 33 about the QoS to be assigned to the user, and generates a token. At this time, the public key Kuap included in the user information part is included in the QoS control part. Further, it constitutes QoS control information and issuing agency information, and the information for SIP that is information to be notified to the UAS 5 is encrypted in the user information section with the user key Ku of the UAS 5. Therefore, it is necessary to search for the Ku of UAS from the user ID of UAS 5. The other parts are dummy information. Further, the session information group of the QoS control information section is for two sessions, and [incoming side, outgoing side] = [SIP server, UAC] and [UAS, UAC]. However, if the QoS setting between the SIP server and the UAC is not necessary, the session information of (SIP server, UAC) may be omitted and one session may be provided.

  Next, the created token and the extracted temporary key Kt are transmitted to the SIP server 62, and a token response is made (step S27). Then, the SIP server 62 completes the session information entry. Even when there is no session information between the SIP server and the UAC in the QoS control unit, it is necessary to register the session information entry. This is because, as a result, QoS setting by token is not performed, but unless session management is performed, UAC cannot update the token. Since the SIP information is already included in the user information portion of the token received from the resource management server 3, the SIP server additionally writes normal user information for UAC.

  Next, the SIP server 62 further generates a server information part, a user information part, and a time stamp / authenticator part from the received token, and transmits them to the UAC as an AUTHENTICATED token (step S28). The edge router between the SIP servers 61 and 62 and the UAC 4 checks the QoS control unit of the AUTHENTICATED token, and if there is a description related to the session, performs QoS setting (Diffserv).

  Next, the UAC 4 that has received the AUTHENTICATED token searches the session information entry based on the Session portion, decrypts the user information portion of the received token with the temporary key Kt, and completes the session information entry. What is registered as session information relates to a session between UAS-UAC and between UAC-SIP servers. And since it is rewritten at the time of the communication between UAC-UAS, the server information part of a token is preserve | saved in a session information entry.

  Next, the UAC 4 transforms the AUTHENTICATED token and transmits it as a REQUEST token to the UAS 5 (step S29). After the user information part of the AUTHENTICATED token is decrypted with the temporary key Kt, only the SIP information part is set as a new user information part. Encryption is not necessary because it is already done with Ku of UAS. A token transmitted and received between UAC and UAS uses a digital signature instead of HMAC-MD5 in the authenticator part. This signature uses the secret key Kuas generated by the UAC, and the calculation range is the same as in the case of using HMAC-MD5.

  When the UAS 5 receives the REQUEST token, the session information entry is searched from the session part of the token to check whether there is a corresponding session. If there is, the user information part is decrypted with its own Ku. Discard. Also, information such as the secret key Kuas and the temporary key Kt is read from the user information part and registered in the session information entry. Then, the UAS 5 creates an ACCEPTED token and transmits it to the UAC 4 (step S30). In the user information part, 0 is stored in the original session information and sequence number, and encrypted with the temporary key Kt. Further, the sequence number generated by UAS 5 is stored in the server information part, encrypted with the temporary key Kt, and a digital signature is used instead of HMAC-MD 5 for the authenticator part. This signature uses a secret key Kuas generated by the UAC4.

  Next, the edge router between UAC and UAS checks the session information group of the QoS control unit. Since the P2P flag is set for the UAC-UAS session, the public key Kuap included in the QoS control unit is used to verify the digital signature attached to the token. If it is not correct, discard it on the spot.

  Next, the UAC 4 that has received the ACCEPTED token searches the session information entry based on the Session portion, decrypts the user information portion of the received token with Kt, and completes the session information entry. The server information part is also decoded and registered as the next sequence number, and at the same time, timer management for performing refresh is started. The handling of the time difference is the same as the procedure described above. With the above operation, QoS between UAC and UAS is set.

  In FIG. 6, the transmission timing of the INITIAL token is after SIP INVITE, but this may be reversed. What is important is that the INITIAL token arrives at the server before the authentication procedure performed at the SIP level is completed. Further, when SIP authentication is not performed, it may be considered that authentication is successful. In FIG. 6, UAC media information is acquired after SIP authentication. However, after the first INVITE (in this case, the INITIAL token needs to arrive first), the UAC 200 receives the UAC media information. / After receiving OK. When using SIP, the user ID is preferably a URI.

  Next, with reference to FIG. 8, an operation for maintaining QoS between UAC and UAS during a session will be described. First, the QoS lifetime related to each session is monitored by the UAC 4 (calling side), and the UAC 4 transmits a REFRESH token to the UAS 5 when about half of the time limit has elapsed (step S41). The user information is the previously acquired sequence number (next sequence number) and is encrypted with the temporary key Kt.

  When the UAS 5 receives the REFRESH token, the session information entry is searched from the session portion of the token to check whether there is a corresponding session. If there is, the user information portion and the server information portion are decrypted with the temporary key Kt, Further check whether the sequence number is present or not, if not, discard the token. If there is no corresponding session, the token is discarded. Then, the UAS 5 creates an ACCEPTED token and transmits it to the UAC 4 (step S42).

  Next, the edge router between UAC and UAS checks the session information group of the QoS control unit. Since the P2P flag is set for the UAC-UAS session, the digital signature added to the token is verified using the public key Kuap included in the QoS control unit. Update time. The UAC 4 that has received the ACCEPTED token searches the session information entry based on the Session part, decrypts the user information part of the received token with the temporary key Kt, and completes the session information entry. The server information part is also decoded and registered as the next sequence number. At the same time, the timer management for refreshing is updated.

  As shown in FIG. 9, in the case of token refresh between UAC-SIP servers, the SIP server transmits the REFRESH token (step S51) received from the UAC 4 to the resource management server 3 as a QoS request (step S51). Based on the token response (step S52), the SIP server 62 transmits an AUTHENTICATED token to the UAC 4 (step S53), whereby the token lifetime is updated. Most of the information necessary for the resource management server 3 is described in the QoS control section and the issuing institution information section. If it is desired to regenerate the public key, the UAC 4 generates a new public key pair at the timing of this REFRESH. Can be incorporated into the user information section. Note that refreshing between UAC and SIP servers is essential to update the token lifetime. Also, since the token has been updated, the user information part of the AUTHENTICATED token includes new SIP information. After receiving the AUTHENTICATED token, the UAC sends a REQUEST token to the UAS in exactly the same manner as S29 and S30 in FIG. Need to be sent and receive the ACCEPTED token.

  In this way, by using tokens, QoS maintenance management (lifetime update) processing set in the router can be distributed, so that the central server does not have to manage everything, and the efficiency of the entire network system Can be improved. In addition, by introducing a direction in which QoS setting can be performed, an illegal resource allocation request can be prevented. Also, with respect to P2P communication using SIP, QoS between SIP clients can be managed in the same manner.

It is a figure which shows the structure of the whole network system in one Embodiment of this invention. It is a block diagram which shows the structure of the resource management server 3 shown in FIG. It is explanatory drawing which shows the structure of a token. It is a sequence diagram which shows the resource allocation operation | movement in the system shown in FIG. It is a sequence diagram which shows the resource allocation operation | movement in the system shown in FIG. It is a sequence diagram which shows the resource allocation operation | movement in the system shown in FIG. It is a sequence diagram which shows the resource allocation operation | movement in the system shown in FIG. It is a sequence diagram which shows the resource allocation operation | movement in the system shown in FIG. It is a sequence diagram which shows the resource allocation operation | movement in the system shown in FIG. It is explanatory drawing which shows operation | movement of COPS-RSVP by a prior art. It is explanatory drawing which shows the operation | movement of the resource allocation in consideration of the session by a prior art.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 1 ... User terminal (EH), 2 ... Application server (APPS), 3 ... Resource management server (RS), 31 ... User information management part, 32 ... Signaling processing part, 33. .... QoS management unit, 4 ... SIP client (UAC), 5 ... SIP client (UAS), 61, 62 ... SIP server, 71-76, 8 ... Router

Claims (11)

A network system including a resource management server for setting QoS for the router to perform information communication between the originating device and the terminating device via the router,
Means for receiving a response to the QoS generation request sent by the called device to the resource management server;
Means for transmitting a token including QoS setting information from the receiver device to the transmitter device;
Means for setting the QoS of the router based on the QoS setting information included in the token.   The router sets QoS based on the QoS setting information when the destination address of the token is the transmitting side device and the transmission source address of the token is the receiving side device. The network system according to claim 1.   The token has a lifetime, and during the token lifetime period, the QoS lifetime of the router can be updated without transmitting the QoS generation request to the resource management server. The network system according to claim 1 or 2.   The network system according to claim 1, wherein the router sets QoS based on the QoS setting information when the validity of the token is confirmed.   5. The information in the token is encrypted using a different encryption key every time information communication is performed between the originating device and the terminating device. 6. Network system. A resource allocation method in a network system including a resource management server for setting QoS for the router to perform information communication between the originating device and the terminating device via the router,
Receiving a response to the QoS generation request sent by the called device to the resource management server;
Transmitting a token including QoS setting information from the receiving device to the calling device;
Setting the QoS of the router based on the QoS setting information included in the token. A resource allocation program that operates on a network system provided with a resource management server for setting QoS for the router in order to perform information communication between the originating device and the terminating device via the router. There,
A process of receiving a response to the QoS generation request sent by the called device to the resource management server;
A process of transmitting a token including QoS setting information from the incoming device to the outgoing device;
A resource allocation program that causes a computer to perform a process of setting QoS of the router based on the QoS setting information included in the token.   The process for setting the QoS of the router is to set the QoS based on the QoS setting information when the destination address of the token is the originating device and the source address of the token is the terminating device. The resource allocation program according to claim 7, wherein:   The token has a lifetime, and during the token lifetime period, the QoS lifetime of the router can be updated without transmitting the QoS generation request to the resource management server. The resource allocation program according to claim 7 or 8.   The process for setting the QoS of the router sets the QoS based on the QoS setting information when the validity of the token can be confirmed. Resource allocation program.   The information in the token is encrypted using a different encryption key each time information communication is performed between the originating device and the terminating device. Resource allocation program.

Images