[go: up one dir, main page]

KR20180070677A - 리소스 획득 방법 및 장치 - Google Patents

리소스 획득 방법 및 장치 Download PDF

Info

Publication number
KR20180070677A
KR20180070677A KR1020187014164A KR20187014164A KR20180070677A KR 20180070677 A KR20180070677 A KR 20180070677A KR 1020187014164 A KR1020187014164 A KR 1020187014164A KR 20187014164 A KR20187014164 A KR 20187014164A KR 20180070677 A KR20180070677 A KR 20180070677A
Authority
KR
South Korea
Prior art keywords
resource
server side
information
device used
client
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.)
Granted
Application number
KR1020187014164A
Other languages
English (en)
Other versions
KR102128356B1 (ko
Inventor
웨이핑 수
수청 류
Original Assignee
후아웨이 테크놀러지 컴퍼니 리미티드
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 후아웨이 테크놀러지 컴퍼니 리미티드 filed Critical 후아웨이 테크놀러지 컴퍼니 리미티드
Publication of KR20180070677A publication Critical patent/KR20180070677A/ko
Application granted granted Critical
Publication of KR102128356B1 publication Critical patent/KR102128356B1/ko
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • 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
    • H04L67/16—
    • 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/04—Network management architectures or arrangements
    • H04L41/045—Network management architectures or arrangements comprising client-server management architectures
    • 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/0866—Checking the configuration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5061—Pools of addresses
    • H04L67/42—
    • 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/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/133—Protocols for remote procedure calls [RPC]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

본원의 실시예들은 리소스 획득 방법을 제공한다. 서버 측은 서버 측에 의해 요청된 리소스에 관한 정보를 포함하는 리소스 요청을 획득한다. 서버 측은 리소스 요청을 클라이언트에 송신한다. 클라이언트는 리소스 요청을 수신한 후에, 서버 측에 요청된 리소스에 관한 정보에 따라, 서버 측에 할당된 리소스에 관한 정보를 획득한다. 클라이언트는 서버 측에 할당된 리소스에 관한 정보를 포함하는 리소스 응답을 서버 측에 송신한다. 본원의 실시예들에서 제공되는 방법에서, 서버 측은 능동적으로, 클라이언트에게, 리소스를 요청하는 데 사용되는 리소스 요청을 송신하고, 서버 측의 리소스 요청에 따라 클라이언트에 의해 서버 측에 할당된 리소스는 서버 측의 실제 요구사항을 보다 잘 만족시킬 수 있어서, 리소스 낭비 가능성을 감소시키는 데 도움을 준다.

Description

리소스 획득 방법 및 장치
본원은 2015년 10월 23일에 중국 특허청에 제출된 "리소스 획득 방법 및 장치"라는 제목의 중국 특허출원 제201510697563.5호의 우선권을 주장하며, 그 전문이 여기에 참고로 통합된다.
본원은 통신 분야에 관한 것으로, 특히, 리소스 획득 방법, 서버 측으로서 사용되는 장치, 및 클라이언트로서 사용되는 장치에 관한 것이다.
NETCONF 프로토콜은 IETF(Internet Engineering Task Force)의 NETCONF 워킹 그룹(working group)에 의해 소개된 새로운 네트워크 구성 프로토콜(Network Configuration Protocol)이다. 네트워크 관리에서의 NETCONF의 기능은 SNMP(Simple Network Management Protocol)와 유사하고, 네트워크 관리자와 장치 사이의 인터페이스 상호 작용 및 데이터 전송에 사용된다. 네트워크 환경에서, 리소스 관리자는 인터넷 프로토콜(IP: Internet Protocol) 어드레스 풀(pool) 및 포워딩(forwarding) 엔트리와 같이, 네트워크 디바이스의 복수의 리소스를 함께 관리하도록 구성된다. NETCONF 프로토콜은 리소스 관리자와 네트워크 장치 사이에 사용되고, 리소스 관리자는 NETCONF 프로토콜에 기초하여 네트워크 장치에 리소스를 할당할 수 있다. 현재 리소스 할당 방식에서, 리소스 낭비 문제가 존재한다.
본원은 리소스를 절약하는 것을 돕기 위해, 리소스 획득 방법, 서버 측으로서 사용되는 장치, 및 클라이언트로서 사용되는 장치를 제공한다.
전술한 목적을 달성하기 위해, 본원은 다음의 기술적 해결책을 제공한다.
본원의 제1 양태는 서버 측이, 서버 측에 의해 요청된 리소스에 관한 정보를 포함하는 리소스 요청을 획득하는 단계, 클라이언트에 리소스 요청을 송신하는 단계, 그리고 서버 측이, 클라이언트에 의해 송신된, 서버 측에 할당된 리소스에 관한 정보를 포함하는 리소스 응답을 수신하는 단계를 포함하는 리소스 획득 방법을 제공한다.
본원의 제2 양태는 클라이언트가, 서버 측에 의해 송신된, 서버 측에 의해 요청된 리소스에 관한 정보를 포함하는 리소스 요청을 수신하는 단계, 서버 측에 의해 요청된 리소스에 관한 정보로서 리소스 요청 내에 포함된 정보에 따라, 서버 측에 할당된 리소스에 관한 정보를 획득하는 단계, 그리고 클라이언트가, 서버 측에 할당된 리소스에 관한 정보를 포함하는 리소스 응답을 서버 측에 송신하는 단계를 포함하는 다른 리소스 획득 방법을 제공한다.
상기의 두 양태들로부터, 본원의 실시예들에서 제공된 리소스 획득 방법에서, 서버 측은 서버 측에 의해 요청된 리소스에 관한 정보를 포함하는 자원 요청을 획득한다는 것을 알 수 있다. 서버 측은 클라이언트에 리소스 요청을 송신한다. 리소스 요청를 수신한 후, 클라이언트는 서버 측에 의해 요청된 리소스에 관한 정보에 따라, 서버 측에 할당된 리소스에 관한 정보를 획득한다. 클라이언트는 서버 측에 할당된 리소스에 관한 정보를 포함하는 리소스 응답을 서버 측에 송신한다. 본원의 실시예들에서 제공되는 방법에서, 서버 측은 능동적으로, 클라이언트에게, 리소스를 요청하는 데 사용되는 리소스 요청을 송신하고, 서버 측의 리소스 요청에 따라 클라이언트에 의해 서버 측에 할당된 리소스는 서버 측의 실제 요구사항을 보다 잘 만족시킬 수 있어서, 리소스 낭비 가능성을 감소시키는 데 도움을 준다.
제1 양태의 구현으로, 방법은 서버 측이 리소스 요청을 획득하기 전에, 서버 측이 서버 측에 의해 사용된 리소스가 조건을 만족하는지를 판단하는 단계를 더 포함하고, 조건은 서버 측의 리소스 사용 상황을 나타내는 데 사용된다.
이 구현에 기초하여, 서버 측은 다음의 특정 구현, 서버 측에 의해 사용된 리소스가 조건을 만족한다고 판단하는 때, 서버 측이, 서버 측에서 사용된 리소스 및 조건에 따라 리소스 요청을 생성하는 단계로 리소스 요청을 획득한다.
서버 측은 리소스 사용 상황에 따라 리소스 요청을 송신하여, 요청된 리소스가 서버 측의 요구 사항을 만족하므로, 리소스 낭비를 더욱 감소시킨다.
제1 양태의 다른 구현으로, 방법은 서버 측과 액티브 클라이언트 사이의 통신이 정상이라고 판단하는 때, 서버 측이, 액티브 클라이언트를 클라이언트로서 선택하는 단계를 더 포함한다.
제1 양태의 다른 구현으로, 방법은 서버 측과 액티브 클라이언트 사이의 통신이 비정상이라고 판단하는 때, 서버 측이 대응관계 및 액티브 클라이언트에 따라 스탠바이 클라이언트를 클라이언트로서 선택하는 단계를 더 포함하고, 대응관계는 액티브 클라이언트에 관한 정보 및 스탠바이 클라이언트에 관한 정보를 포함한다.
액티브 클라이언트와 스탠바이 클라이언트 모두가 존재하는 때, 서버 측은 단 하나의 클라이언트에 리소스 요청을 송신하여, 전송 리소스가 감소될 수 있다는 것을 알 수 있다.
본원의 제3 양태는 리소스 요청을 획득하도록 구성된 획득 모듈, 클라이언트로서 사용되는 장치에 리소스 요청을 송신하도록 구성된 송신 모듈, 그리고 클라이언트로서 사용되는 장치에 의해 송신된 리소스 응답을 수신하도록 구성된 수신 모듈을 포함하고, 리소스 요청은 서버 측으로서 사용되는 장치에 의해 요청된 리소스에 관한 정보를 포함하고, 리소스 응답은 서버 측으로서 사용되는 장치에 할당된 리소스에 관한 정보를 포함하는 서버 측으로서 사용되는 장치를 제공한다.
제3 양태에서 제공되는, 서버 측으로서 사용되는 장치는 클라이언트로서 사용되는 장치에 리소스 요청을 능동적으로 송신함으로써, 리소스 낭비 가능성을 감소시키는 것을 돕는다.
선택적으로, 제3 양태의 구현으로, 장치는 서버 측으로서 사용되는 장치에 의해 사용된 리소스가 조건을 만족하는지를 판단하도록 구성된 판단 모듈을 더 포함하고, 조건은 서버 측의 리소스 사용 상황을 나타내는 데 사용된다.
선택적으로, 제3 양태의 전술한 구현에 기초하여, 제1 획득 모듈은 다음의 특정 구현, 서버 측으로서 사용되는 장치에 의해 사용된 리소스가 조건을 만족한다고 판단한 때, 서버 측으로서 사용되는 장치에서 사용된 리소스 및 조건에 따라 리소스 요청을 생성하는 단계로, 리소스 요청을 획득한다.
제3 양태의 다른 구현으로, 장치는 제1 송신 모듈이, 클라이언트로서 사용되는 장치에 리소스 요청을 송신하기 전에, 서버 측으로서 사용되는 장치와 클라이언트로서 사용되는 액티브 장치 사이의 통신이 정상이라고 판단하는 때, 서버 측으로서 사용되는 장치가, 액티브 장치를 클라이언트로서 사용되는 장치로서 선택하도록 구성된 제1 선택 모듈을 더 포함한다.
제3 양태의 다른 구현으로, 장치는 제1 송신 모듈이, 클라이언트로서 사용되는 장치에 리소스 요청을 송신하기 전에, 서버 측으로서 사용되는 장치와 클라이언트로서 사용되는 액티브 장치 사이의 통신이 비정상이라고 판단한 때, 대응관계 및 클라이언트로서 사용되는 액티브 장치에 따라 클라이언트로서 사용되는 스탠바이 장치를 클라이언트로서 사용되는 장치로서 선택하도록 구성된 제2 선택 모듈을 더 포함하고, 대응관계는 클라이언트로서 사용되는 액티브 장치에 관한 정보 및 클라이언트로서 사용되는 스탠바이 장치에 관한 정보를 포함한다.
본원의 제4 양태는 서버 측으로서 사용되는 장치에 의해 송신된 리소스 요청을 수신하도록 구성된 수신 모듈 - 리소스 요청은 서버 측으로서 사용되는 장치에 의해 요청된 리소스에 관한 정보를 포함함 -, 서버 측으로서 사용되는 장치에 의해 요청된 리소스에 관한 정보로서 리소스 요청 내에 포함된 정보에 따라, 서버 측으로서 사용되는 장치에 할당된 리소스에 관한 정보를 획득하도록 구성된 획득 모듈, 그리고 서버 측으로서 사용되는 장치에 리소스 응답을 송신하도록 구성된 송신 모듈 을 포함하고, 리소스 응답은 서버 측으로서 사용되는 장치에 할당된 리소스에 관한 정보를 포함하는, 클라이언트로서 사용되는 장치를 제공한다.
본원의 제5 양태는 프로세서, 프로세서와 함께 사용되는 메모리, 및 통신 인터페이스를 포함하는, 서버 측으로서 사용되는 장치를 제공한다. 메모리는 리소스 획득 기능을 구현하는 프로그램을 저장하고, 프로세서는 메모리 및 통신 인터페이스에서 프로그램을 호출하여 다음의 기능들, 리소스 요청을 획득하는 단계, 클라이언트로서 사용된 장치에 리소스 요청을 송신하는 단계, 그리고 클라이언트로서 사용되는 장치에 의해 송신된 리소스 응답을 수신하는 단계를 구현하고, 여기서 리소스 요청은 서버 측으로서 사용되는 장치에 의해 요청된 리소스에 관한 정보를 포함하며, 리소스 응답은 서버 측으로서 사용되는 장치에 할당된 리소스에 관한 정보를 포함한다.
본 출원의 제6 양태는 프로세서, 프로세서와 함께 사용되는 메모리, 및 통신 인터페이스를 포함하는, 클라이언트로서 사용되는 장치를 제공한다. 메모리는 리소스 획득 기능을 구현하는 프로그램을 저장하고, 프로세서는 메모리 및 통신 인터페이스에서 프로그램을 호출하여 다음의 기능들, 서버 측에 의해 송신된 리소스 요청을 수신하는 단계, 서버 측에 의해 요청된 리소스에 관한 정보로서 리소스 요청 내에 포함된 정보에 따라, 서버 측에 할당된 리소스에 관한 정보를 획득하는 단계, 그리고 서버 측에 리소스 응답을 송신하는 단계를 구현하고, 리소스 요청은 서버 측에 의해 요청된 리소스에 관한 정보를 포함하고, 리소스 응답은 서버 측에 할당된 리소스에 관한 정보를 포함한다.
본원의 제1, 제2, 제3, 제4, 제5, 제6 양태들의 일부 구현들로, 리소스 요청은 NETCONF(network configuration) 프로토콜에 기초한 통지(notification) 메시지를 포함하고, 통지 메시지는 서버 측에 의해 요청된 리소스에 관한 정보를 포함하며, 리소스 응답은 NETCONF 프로토콜에 기초한 RPC(remote procedure call) 메시지를 포함하고, RPC 메시지는 서버 측에 할당된 리소스에 관한 정보를 포함한다.
본원의 제1, 제2, 제3, 제4, 제5, 제6 양태들의 일부 구현들로, 리소스 요청은 RESTCONF 프로토콜에 기초한 통지 메시지를 포함하고, 통지 메시지는 서버 측에 의해 요청된 리소스에 관한 정보를 포함하며, 리소스 응답은 RESTCONF 프로토콜에 기초한 포스트(post) 메시지를 포함하고, 포스트 메시지는 서버 측에 할당된 리소스에 관한 정보를 포함한다.
본원의 제1, 제2, 제3, 제4, 제5, 제6 양태들의 일부 구현들로, 리소스 요청은 획득 메시지를 포함하고, 획득 메시지는 서버 측에 의해 요청된 리소스에 관한 정보를 포함하며, 리소스 응답은 응답 메시지를 포함하고, 응답 메시지는 서버 측에 할당된 리소스에 관한 정보를 포함하며, 응답 메시지는 획득 메시지에 응답하는 데 사용된다.
본원의 제1, 제2, 제3, 제4, 제5, 제6 양태들의 일부 구현들로, 서버 측에 의해 요청된 리소스에 관한 정보는 서버 측에 의해 요청된 리소스의 제1 액션 유형 및 파라미터를 포함하고, 제1 액션 유형은 서버 측에 의해 요청된 리소스에 대해 수행된 동작을 나타내는 데 사용되며, 서버 측에 할당된 리소스에 관한 정보는 제2 액션 유형 및 서버 측에 할당된 리소스의 파라미터를 포함하고, 제2 액션 유형은 서버 측에 할당된 리소스에 대해 수행된 동작을 나타내는 데 사용된다.
본원의 제1, 제2, 제3, 제4, 제5, 제6 양태들의 일부 구현들로, 서버 측에 의해 요청된 리소스에 관한 정보는 제1 액션 유형, 제1 식별자, 및 서버 측에 의해 요청된 리소스의 파라미터를 포함하고, 제1 액션 유형은 서버 측에 의해 요청된 리소스에 대해 수행된 동작을 나타내는 데 사용되며, 제1 식별자는 리소스 요청의 순서를 나타내는 데 사용되고, 서버 측에 할당된 리소스에 관한 정보는 제2 식별자 및 서버 측에 할당된 리소스의 파라미터를 포함하고, 제2 식별자는 리소스 응답의 순서를 나타내는 데 사용되며, 제2 식별자는 제1 식별자에 대응한다.
도 1은 클라이언트와 서버 측이 NETCONF 프로토콜을 사용하여 리소스 구성을 수행하는 개략도이다.
도 2는 본원의 실시예에 따른 리소스 획득 방법의 순서도이다.
도 3은 본원의 실시예에 따른 다른 리소스 획득 방법의 순서도이다.
도 4는 액티브 클라이언트와 스탠바이 클라이언트가 NETCONF 프로토콜을 사용하여 서버 측과 통신하는 개략도이다.
도 5는 본원의 실시예에 따른 다른 리소스 획득 방법의 순서도이다.
도 6은 본원의 실시예에 따른 서버 측으로서 사용되는 장치의 개략적인 구조도이다.
도 7은 본원의 실시예에 따른 클라이언트로서 사용되는 장치의 개략적인 구조도이다.
도 8은 본원의 실시예에 따른 서버 측으로서 사용되는 다른 장치의 개략적인 구조도이다.
도 9는 본원의 실시예에 따른 클라이언트로서 사용되는 다른 장치의 개략적인 구조도이다.
일반적인 리소스 구성 프로세스에서, 클라이언트로서 사용되는 리소스 관리 디바이스와 서버 측으로서 사용되는 네트워크 디바이스 사이에서, NETCONF 프로토콜을 사용하여 리소스 구성이 수행될 수 있다. 예를 들어, 도 1에 도시된 시나리오에서, 클라이언트로서 사용되는 리소스 관리 디바이스는 서버 측으로서 사용되는 네트워크 디바이스에 어드레스 범위를 전송하고, 어드레스 범위는 사용할 서버 측으로서 사용되는 네트워크 디바이스에 대해 구성된 어드레스 범위이다. 네트워크 디바이스는 어드레스 범위에 따라 어드레스 풀을 생성한다. 리소스 관리 디바이스는 수동 설정에 따라 어드레스 범위를 선택한다. 따라서, 수동 설정에 의해 네트워크 디바이스의 어드레스 사용량이 추정되는 때 발생하는 편차에 의해 야기된 네트워크 디바이스의 처리 능력 부족을 방지하기 위해, 수동 설정에 의해 네트워크 디바이스에 할당된 어드레스 범위는 네트워크 디바이스에 의해 실제로 요구되는 어드레스 범위보다 더 크고, 결과적으로 대량의 유휴 어드레스 리소스가 네트워크 디바이스 상에 존재하며, 네트워크 디바이스 상의 대량의 유휴 어드레스 리소스가 다른 네트워크 디바이스에 의해 사용될 수 없기 때문에 리소스 낭비가 야기된다.
본원의 실시예들에서 제공된 방법 및 장치는 리소스 낭비 문제를 해결하는 것을 도울 수 있다.
본 발명의 실시예들의 목적, 기술적 해결책, 및 장점들을 보다 명확하게 하기 위해, 본 발명의 실시예들에서 첨부한 도면들을 참조하여 본 발명의 실시예들에서의 기술적 해결책을 명확하게 설명한다. 명백하게, 기술된 실시예들은 본 발명의 실시예들 중 일부이다.
본원의 실시예들에서 제공되는 방법에서, 서버 측은 리소스 요청을 획득하고, 리소스 요청은 클라이언트의 어드레스 및 서버 측에 의해 요청된 리소스에 관한 정보를 포함한다. 서버 측은 클라이언트의 어드레스에 따라 클라이언트에 리소스 요청을 송신한다. 클라이언트는 서버 측에 의해 송신된 리소스 요청을 수신한다. 클라이언트는 서버 측에 의해 요청된 리소스에 관한 정보로서 리소스 요청에 포함되어 있는 정보에 따라, 서버 측에 할당된 리소스에 관한 정보를 획득한다. 클라이언트는 서버 측에 리소스 응답을 송신하고, 리소스 응답은 서버 측에 할당된 리소스에 관한 정보를 포함한다. 서버 측은 클라이언트에 의해 송신된 리소스 응답을 수신한다. 이 방식으로, 서버 측은 서버 측에 할당된 리소스에 관한 정보로서 리소스 응답에 포함되어 있는 정보에 따라, 서버 측에 의해 요구되는 리소스를 획득할 수 있어서, 리소스 낭비를 감소시키는 데 도움을 준다.
본원의 실시예들에서 제공되는 방법 및 장치는 도 1에 도시된 시나리오에 적용될 수 있다. 본원의 실시예에서 언급된 서버 측은 도 1의 네트워크 디바이스일 수 있다. 대안적으로, 본원의 실시예에서 언급된 서버 측은 라우터, 스위치, 서버, 가상화된 네트워크 기능(VNF: Virtualized Network Function), 또는 VNF의 관리 시스템과 같이, 구성 기능을 구현하는 프로토콜 내의 서버 측으로서 정의된 장치일 수 있다. VNF의 관리 시스템은 VNF 관리자(VNFM: VNF manager) 및 NFV 오케스트레이터(NFVO: NFV Orchestrator)를 포함한다. 구성 기능을 구현하는 프로토콜은 NETCONF 프로토콜 또는 RESTCONF 프로토콜과 같은 프로토콜일 수 있다. 구성 기능을 구현하는 프로토콜 내에 포함된 모든 프로토콜은 여기에서 하나씩 설명하지 않는다. 본원의 실시예들에서 언급된 클라이언트는 도 1의 리소스 관리 디바이스일 수 있다. 대안적으로, 본원의 실시예들에서 언급된 클라이언트는 라우터, 스위치, 서버, 또는 제어기와 같이, 구성 기능을 구현하는 프로토콜에서 클라이언트로서 정의된 장치일 수 있다. 클라이언트에 사용되는 장치와 서버 측으로서 사용되는 장치 모두는 구성 기능을 구현하는 프로토콜을 지원한다.
세션은 구성 기능을 구현하는 프로토콜을 사용하여 서버 측과 클라이언트 사이에 설정될 수 있으며, 예를 들어, NETCONF 프로토콜을 사용하여 서버 측과 클라이언트 사이에 NETCONF 세션이 설정될 수 있거나, 또는 RESTCONF 프로토콜을 사용하여 서버 측과 클라이언트 사이에 RESTCONF RESTCONF 세션이 설정될 수 있다. 서버 측에 의해 클라이언트로부터 리소스를 획득하는 방법은 도 1의 시나리오를 참조하여 후술한다. 도 2에 도시된 바와 같이, 본원의 이 실시예에서 제공되는 리소스 획득 방법은 다음 단계들을 포함한다.
S201. 서버 측은 리소스 요청을 획득하고, 여기서 리소스 요청은 서버 측에 의해 요청된 리소스에 관한 정보를 포함한다.
예를 들어, 서버 측에 의해 요청된 리소스는 서버 측에 의해 서비스를 완료하는 데 요구되는 리소스일 수도 있거나, 다른 디바이스를 구성하는 데 요구되는 리소스일 수도 있다. 예를 들어, 서버 측은 광대역 네트워크 게이트웨이(BNG: Broadband Network Gateway)이다. BNG가 사용자에게 어드레스를 할당하는 서비스를 완료해야 하면, BNG는 미리 어드레스 풀과 포워딩 엔트리를 획득해야 하며, 즉, BNG에 의해 요청된 리소스는 어드레스 풀과 포워딩 엔트리를 포함한다.
구체적으로, 서버 측에 의해 요청된 리소스에 관한 정보는 제1 액션 유형 및 서버 측에 의해 요청된 리소스의 파라미터를 포함한다. 서버 측에 의해 요청된 리소스의 파라미터는 서비스를 완료하기 위해 서버 측에 의해 요구되는 리소스에 포함된 필수 파라미터이다. 예를 들어, 서버 측이 어드레스 할당 서비스를 완료해야 하면, 어드레스 할당 서비스를 완료하기 위해 서버 측에 의해 요구되는 리소스는 어드레스 풀이며, 서버 측에 의해 요청된 리소스의 파라미터는 어드레스 풀에 관련된 파라미터이다. 제1 액션 유형은 서버 측에 의해 요청된 리소스에 대해 수행된 액션을 나타내는 데 사용된다. 서버 측에 의해 요청된 리소스의 파라미터가 어드레스 풀과 관련된 파라미터이면, 제1 액션 유형은 "요청", "해제", 또는 "임대 갱신"일 수 있다.
예를 들어, 서버 측에 의해 요청된 리소스의 파라미터에 포함된 내용은 제1 액션 유형의 다른 내용에 따라 달라진다. 예를 들어, 서버 측에 의해 요청된 리소스는 어드레스 풀이고, 제1 액션 유형은 "요청"이다. 서버 측에 의해 요청된 리소스의 파라미터는 어드레스 풀의 유형을 포함한다. 선택적으로, 서버 측에 의해 요청된 리소스의 파라미터는 어드레스 풀에 포함된 어드레스의 수량을 더 포함할 수 있다. 어드레스 풀의 유형은 IPv4 또는 IPv6일 수 있다.
예를 들어, 서버 측에 의해 요청된 리소스는 어드레스 풀이고, 제1 액션 유형은 "임대 갱신"이다. 서버 측에 의해 요청된 리소스의 파라미터는 어드레스 풀의 명칭을 포함한다. 임대 갱신의 액션을 수신한 후에, 클라이언트는 지정된 유효 기간에 따라, 서버 측에 의해 송신된 어드레스 풀을 유효 기간까지 연장할 수 있다. 선택적으로, 서버 측에 의해 요청된 리소스의 파라미터는 유효 기간을 더 포함할 수 있다.
예를 들어, 서버 측에 의해 요청된 리소스는 어드레스 풀이고, 제1 액션 유형은 "해제"이다. 서버 측에 의해 요청된 리소스의 파라미터는 어드레스 풀의 명칭을 포함한다. 선택적으로, 서버 측에 의해 요청된 리소스의 파라미터는 어드레스 풀의 어드레스 범위를 더 포함할 수 있다. 어드레스 풀의 어드레스 범위는 서버 측에 의해 요청된 어드레스 풀의 하위 집합일 수 있거나, 또는 서버 측에 의해 요청된 어드레스 풀일 수 있다.
"요청"은 서버 측이 충분한 어드레스 리소스 풀을 갖지 않는 때, 서버 측이, 클라이언트로부터 사용 가능한 어드레스 풀을 요청하는 액션이다. "해제 갱신"은 서버 측에 의해 요청된 어드레스 풀이 유효 기간에 도달하기 전에 다시 유효 기간에 대해서 신청하는 동작이다. 유효 기간은 2050년 12월 20일과 같은 종료 시간일 수 있거나, 또는 이틀과 같은 시간 기간일 수 있다. "해제"는 클라이언트가 다른 서버 측에 임의의 시간 기간 내에서 서버 측에 의해 사용되지 않는 어드레스 풀을 할당하는 액션이다. 이 실시예에서 어드레스 풀은 어드레스의 세그먼트, 예를 들어, IPv4 어드레스 세그먼트(100.100.0.1 내지 100.100.0.254)가 254개의 어드레스 리소스를 포함하는 어드레스 풀이라는 것을 유의해야 한다.
선택적으로, 리소스 요청은 리소스 요청의 식별자를 더 포함할 수 있고, 리소스 요청의 식별자는 리소스 요청의 시퀀스 번호를 나타내는 데 사용된다. 서버 측이 복수의 리소스 요청을 클라이언트에 송신하면, 리소스 요청의 식별자는 복수의 리소스 요청을 구별하는 데 사용될 수 있다. 본원의 이 실시예에서, 리소스 요청의 식별자는 100, 두 번째, 및 숫자 100과 같은 문자 또는 숫자 중 적어도 하나일 수 있다.
S202. 서버 측은 클라이언트에 리소스 요청을 송신한다.
예를 들어, 클라이언트의 IP 어드레스 또는 MAC 어드레스 중 적어도 하나가 서버 측은 구성될 수 있다. 서버 측은 IP 어드레스 또는 MAC 어드레스에 따라 클라이언트에 리소스 요청을 송신할 수 있다. 대안적으로, 클라이언트의 식별자는 서버 측은 구성될 수 있고, 서버 측은 클라이언트의 식별자에 따라 클라이언트의 IP 어드레스 또는 MAC 어드레스 중 적어도 하나를 획득할 수 있다. 서버 측은 IP 어드레스 또는 MAC 어드레스에 따라 클라이언트에 리소스 요청을 송신할 수 있다. 대안적으로, 클라이언트의 식별자와 포트 사이의 대응관계는 서버 측은 구성될 수 있고, 포트는 클라이언트와 통신하기 위해 서버 측에 의해 사용될 수 있는 포트이다. 서버 측은 클라이언트의 식별자에 따라, 클라이언트와 통신하는 데 사용될 수 있는 포트를 획득할 수 있다. 서버 측은 포트를 사용하여 클라이언트에 리소스 요청을 송신할 수 있다.
S203. 리소스 요청을 수신한 후에, 클라이언트는 서버 측에 요청된 리소스에 관한 정보로서 리소스 요청에 포함되어 있는 정보에 따라서, 서버 측에 할당된 리소스에 관한 정보를 획득한다.
예를 들어, 서버 측에 할당된 리소스에 관한 정보는 제2 액션 유형 및 서버 측에 할당된 리소스의 파라미터를 포함하고, 제2 액션 유형은 서버 측에 할당된 리소스에 대해 수행된 동작을 나타내는데 사용된다 .
예를 들어, 서버 측에 의해 요청된 리소스는 어드레스 풀이고, 제1 액션 유형은 "요청"이다. 서버 측에 할당된 리소스의 파라미터는 어드레스 풀의 명칭, 어드레스 풀의 시작 어드레스, 및 어드레스 풀의 종료 어드레스를 포함하고, 제2 액션 유형은 "생성"이다. 선택적으로, 서버 측에 할당된 리소스의 파라미터는 어드레스 풀의 유효 기간 또는 어드레스 풀의 유형 중 적어도 하나를 더 포함할 수 있다. 어드레스 풀의 유형은 IPv4 또는 IPv6일 수 있다. "생성"은 서버 측이 어드레스 풀의 시작 어드레스와 어드레스 풀의 종료 어드레스에 따라, 서버 측의 어드레스 풀의 명칭으로 명명된 어드레스 풀을 생성하는 액션이다.
예를 들어, 서버 측에 의해 요청된 리소스는 어드레스 풀이고, 제1 액션 유형은 "임대 갱신"이다. 서버 측에 할당된 리소스의 파라미터는 어드레스 풀의 명칭 및 어드레스 풀의 유효 기간을 포함하고, 제2 액션 유형은 "갱신"이다. "갱신"은 서버 측이, 어드레스 풀의 유효 기간까지 어드레스 풀의 명칭에 대응하는 어드레스 풀을 사용하기 위해 서버 측은 계속하는 액션이다.
예를 들어, 서버 측에 의해 요청된 리소스는 어드레스 풀이고, 제1 액션 유형은 "해제"이다. 서버 측에 할당된 리소스의 파라미터는 어드레스 풀의 명칭을 포함하고, 제2 액션 유형은 "삭제"이다. 선택적으로, 서버 측에 의해 요청된 리소스의 파라미터는 어드레스 풀의 어드레스 범위를 더 포함할 수 있다. 어드레스 풀의 어드레스 범위는 서버 측에 의해 요청된 어드레스 풀의 하위 집합일 수 있거나, 또는 서버 측에 의해 요청된 어드레스 풀일 수 있다. "삭제"는 서버 측이, 어드레스 풀의 명칭에 대응하는 어드레스 풀의 사용을 포기하는 액션이다.
S204. 클라이언트는 서버 측에 리소스 응답을 송신하고, 여기서 리소스 응답은 서버 측에 할당된 리소스에 관한 정보를 포함한다.
예를 들어, 리소스 응답은 할당된 리소스에 관한 정보를 리소스 요청을 송신하는 장치에 송신하는 데 사용된다. 서버 측에 할당된 리소스에 관한 정보로서 리소스 응답 내에 포함되어 있는 정보는 제2 액션 유형 및 서버 측에 할당된 리소스의 파라미터를 포함한다. 서버 측에 할당된 리소스의 파라미터는 어드레스 풀 또는 포워딩 엔트리와 같은 리소스 명칭, 및 리소스 파라미터를 포함할 수 있다. 제2 액션 유형은 서버 측에 할당된 리소스에 대해 수행된 동작을 나타내는 데 사용된다.
제2 액션 유형이 제1 액션 유형에 대응함을 알 수 있다. 제1 액션 유형 및 제2 액션 유형은 동일한 필드를 사용하여 표현될 수 있거나, 또는 상이한 필드를 사용하여 표현될 수 있다.
선택적으로, 리소스 응답은 리소스 응답의 식별자를 더 가질 수 있다. 리소스 응답의 식별자는 리소스 응답의 시퀀스 번호를 나타내는 데 사용되고, 다른 리소스 응답과 구별되는 데 사용된다.
S205. 서버 측은 리소스 응답에 따라 구성을 수행한다.
예를 들어, 서버 측이 리소스 응답에 따라 구성을 수행하는 것은, 서버 측이 리소스 응답의 제2 액션 유형 및 서버 측에 할당된 리소스의 파라미터에 따라 구성을 수행하는 것, 예를 들어, 어드레스 풀을 생성하거나, 어드레스 풀을 업데이트하거나, 또는 어드레스 풀을 삭제하는 것을 포함한다. 설명을 위해 예제가 여기에 하나씩 제공되지 않는다.
본원에서 제공되는 이 실시예에서, 서버 측은 리소스 요청을 능동적으로 개시한다. 리소스 요청 개시자 및 리소스 사용자 모두는 서버 측이다. 따라서, 서버 측은 요구 사항에 따라 리소스를 신청할 수 있어서, 리소스 유휴 상태를 방지하고, 리소스 활용을 개선하며, 리소스 낭비를 감소시킨다.
선택적으로, S201 전에, 본원에서 제공된 이 실시예는, 서버 측이, 서버 측에 의해 사용되는 리소스가 조건을 만족하는지를 판단하는 단계를 더 포함하고, 여기서 조건은 서버 측의 리소스 사용 상황을 나타내는 데 사용된다. 따라서, 서버 측이 리소스 요청을 획득하는 것은, 서버 측에 의해 사용되는 리소스가 조건을 만족하는 것으로 판정하는 때, 서버 측이, 서버 측에 의해 사용되는 리소스 및 조건에 따라 리소스 요청을 생성하는 단계를 포함한다.
리소스 요청 및 리소스 응답은 각각 식별자를 가질 수 있음을 유의해야 한다. 따라서, 리소스 요청 및 리소스 응답의 전술한 특정 구현에 부가하여, 리소스 요청 및 리소스 응답은 선택적으로 다음과 같은 형태일 수 있다.
리소스 요청은 서버 측에 의해 요청된 리소스에 관한 정보를 포함한다. 또한, 서버 측에 의해 요청된 리소스에 관한 정보는 제1 액션 유형, 제1 식별자, 및 서버 측에 의해 요청된 리소스의 파라미터를 포함한다. 제1 액션 유형은 서버 측에 의해 요청된 리소스에 대해 수행된 동작을 나타내는 데 사용된다. 제1 식별자는 리소스 요청의 순서를 나타내는 데 사용된다.
리소스 응답은 서버 측에 할당된 리소스에 관한 정보를 포함한다. 또한, 서버 측에 할당된 리소스에 관한 정보는 제2 식별자 및 서버 측에 할당된 리소스의 파라미터를 포함한다. 제2 식별자는 리소스 응답의 순서를 나타내는 데 사용된다. 제2 식별자는 제1 식별자에 대응한다.
즉, 도 2의 방법과 비교하여, 리소스 응답은 제2 액션 유형을 포함하지 않을 수 있다. 리소스 응답을 수신한 후, 서버 측은 리소스 응답의 식별자, 리소스 요청 내의 식별자, 리소스 요청의 식별자와 리소스 응답의 식별자 사이의 대응관계에 따라, 리소스 응답에 대응하는 리소스 요청을 판단할 수 있어서, 리소스 응답에 대응하는 리소스 요청 내의 제1 액션 유형에 따라 대응하는 리소스 구성 동작을 수행한다.
NETCONF 프로토콜이 일례로서 사용되며, 서버 측 및 클라이언트가 리소스 구성을 수행하는 특정 프로세스는 도 3에 도시될 수 있고, 다음 단계들을 포함한다.
S301. 서버 측은 서버 측에 의해 사용되는 리소스가 조건을 충족시키는지를 판단하고, 그렇다면 S302를 수행하거나, 또는 그렇지 않으면, 서버 측의 리소스 사용 상황을 계속 모니터링할 수 있다.
조건은 서버 측의 리소스 사용 상황을 나타내는 데 사용된다. 예를 들어, 어드레스 풀이 일례로서 사용된다. 어드레스 풀이 100 개의 어드레스를 포함하고, 조건이 서버 측에 의해 사용되는 어드레스의 개수가 90보다 더 크고 100보다 더 작은 것이고, 91개의 어드레스가 서버 측에 의해 사용되면, 서버 측은 서버 측에 의해 사용되는 리소스가 조건을 만족한다고 판단한다. 서버 측은 서비스 측이 요청한 어드레스 풀이 사용하기에 충분하지 않을 수 있다는 것을 알게 된다. 서버 측은 새로운 어드레스 풀을 요청하는 데 사용되는 리소스 요청을 생성한다. 조건이 서버 측의 어드레스 풀의 유효 기간이 이틀을 초과하는 것이면, 요청된 어드레스 풀이 조건을 만족한다고 판단한 후에, 서버 측은 클라이언트에 임대 갱신을 위한 리소스 요청을 송신한다. 조건이 사용 중이 아닌 어드레스의 개수가 20보다 더 크고 100보다 더 작은 것이고, 21개의 어드레스가 서버 측에 의해 사용되지 않으면, 서버 측은 서버 측에 의해 사용되는 리소스가 조건을 만족한다고 판단한다. 서버 측이 어드레스가 해제될 수 있음을 알게 되면. 서버 측은 어드레스 풀 해제를 요청하는 데 사용되는 리소스 요청을 생성한다.
S302. 서버 측은 서버 측에 의해 사용되는 리소스와 조건에 따라 통지 메시지를 생성한다.
선택적으로, 서버 측이 서버 측에 의해 사용된 리소스 및 조건을 다른 디바이스에 더 전송하여, 다른 디바이스는 사용된 리소스 및 조건에 따라 리소스 요청을 생성할 수 있다. 서버 측은 다른 디바이스에 의해 송신된 리소스 요청을 수신할 수 있다.
예를 들어, 통지 메시지는 서버 측에 의해 요청된 리소스에 관한 정보를 포함한다. 서버 측에 의해 요청된 리소스에 관한 정보의 구체적인 형태에 대해서, S201의 설명을 참조한다. 선택적으로, 서버 측에 의해 요청된 리소스에 관한 정보는 통지 메시지의 페이로드(payload) 필드 내에 포함될 수 있다.
S303. 서버 측은 통지 메시지를 클라이언트에 송신한다.
서버 측은 NETCONF 프로토콜의 규정에 기초하여 클라이언트에게 통지 메시지를 송신할 수 있다. 세부 사항은 여기에 설명되어 있지 않다.
S304. 통지 메시지를 수신한 후, 클라이언트는 RPC(Remote Procedure Call) 메시지를 생성한다.
예를 들어, RPC 메시지는 서버 측에 할당된 리소스에 관한 정보를 포함한다. 구체적인 형식에 대해서, S203의 설명을 참조한다. 선택적으로, 서버 측에 할당된 리소스에 관한 정보는 RPC 메시지의 페이로드(payload) 필드에 포함될 수 있다. 클라이언트는 NETCONF 프로토콜의 규정에 기초하여 RPC 메시지를 송신할 수 있다. 세부 사항은 여기에 설명되어 있지 않다.
S305. 클라이언트는 RPC 메시지를 서버 측에 송신한다.
클라이언트는 NETCONF 프로토콜의 규정에 기초하여 서버 측에 RPC 메시지를 송신할 수 있다. 세부 사항은 여기에 설명되어 있지 않다.
이 실시예에서, RPC 메시지와 기존의 NETCONF 프로토콜 사이의 호환성을 보장하기 위해, 서버 측에 할당된 리소스에 관한 정보 이외에, RPC 메시지는 프로토콜 동작 유형을 더 가진다. 이 실시예에서, RPC 메시지의 프로토콜 동작 유형은 편집-구성이다.
S306. 서버 측은 RPC 메시지에 따라 리소스를 구성한다.
이 실시예에서, 리소스 구성의 내용에 대해서, 도 2에 대응하는 실시예에서의 대응하는 내용을 참조한다. 세부 사항은 여기에서 다시 설명되지 않는다.
S307. 서버 측은 리소스 구성 피드백을 클라이언트에 송신한다.
이 실시예에서, 리소스 구성 피드백은 RPC-응답(RPC-reply) 메시지일 수 있다. RPC-응답 메시지는 클라이언트에게 리소스 구성 결과를 통지하는 데 사용된다. 리소스 구성 결과는 구성 성공 또는 구성 실패이다.
이 실시예의 방법에서, 종래의 통지 메시지 및 RPC 메시지가 개선되어, 서버 측은 개선된 통지 메시지를 사용하여 클라이언트로부터 리소스를 요청할 수 있고, 클라이언트는 RPC 메시지를 사용하여 서버 측에 리소스를 전달할 수 있다. 따라서, 서버 측은 NETCONF 프로토콜 프레임워크 내의 리소스를 적극적으로 요청하여, 리소스 낭비를 감소시킨다.
리소스 요청을 위해 사용되는 통지 메시지 및 리소스 응답을 위해 사용되는 RPC 메시지의 예는 다음과 같다.
<Notification request-message-id=201> //통지 메시지, 메시지의 식별자는 201이다
<event>
<address-pool operation="GET"> //리소스 명칭은 어드레스 풀이고, 제1 액션 유형은 "요청"(GET)이다.
<address-number>254</address-number> //요청된 어드레스의 수량은 254이다.
</event>
</Notification>
<RPC message-id=101> //RPC 요청 메시지, 메시지의 식별자는 101이다.
<edit-config>
<request-message-id>201</request-message-id> //식별자 응답 메시지에 대응하는 요청 통지
<address-pool> //리소스 명칭은 어드레스 풀이다
<address-pool-entry operation="create"> //제2 액션 유형은 "생성"(create)
<name>First_pool</name> //어드레스 풀의 명칭
<ip-lower-address>100.0.0.1</ip-lower-address>
<ip-upper-address>100.0.0.254</ip-lower-address>
<life-time>24H</life-time> //어드레스 풀의 유효 기간은 24 시간이다
</address-pool-entry>
</address-pool>
</edit-config>
</RPC>
<RPC-REPLY message-id=101> //RPC 응답 메시지, 메시지의 식별자는 101이다
<ok/>
</RPC-REPLY>.
유사하게, RESTCONF 프로토콜 프레임워크에서, 서버 측은 RESTCONF 프로토콜에 기초한 통지 메시지에 서버 측에 의해 요청된 리소스에 관한 정보를 추가할 수 있고, 클라이언트에 리소스 요청을 송신할 수 있다. 클라이언트는 RESTCONF 프로토콜에 기초한 포스트(post) 메시지에 서버 측에 할당된 리소스에 관한 정보를 추가할 수 있고, 서버 측에 리소스 응답을 송신할 수 있다. 서버 측에 의해 요청된 리소스에 관한 정보의 특정 내용 및 서버 측에 할당된 리소스에 관한 정보의 특정 내용에 대해서, 도 2 또는 도 3에 대응하는 실시예를 참조한다.
도 4에 도시된 바와 같이, 리소스 관리 시스템에서, 두 개의 클라이언트는 각각 액티브 클라이언트 및 스탠바이 클라이언트로서 설정된다. 액티브 클라이언트와 스탠바이 클라이언트는 각각 서버 측과 NETCONF 세션을 설정한다. 이 시나리오에서, 리소스 구성 프로세스는 도 5에 도시되고, 다음의 단계들을 포함한다.
S501. 서버 측은 네트워크 관리 디바이스 상의 리스트를 쿼리하여 액티브 클라이언트를 판단한다.
예를 들어, 네트워크 관리 디바이스 상의 리스트는 액티브 클라이언트의 식별자 및 스탠바이 클라이언트의 식별자를 포함한다. 네트워크 관리 디바이스 상의 리스트는 서버 측에서 구성된 리스트일 수도 있거나, 또는 리소스 관리 시스템에서 구성된 리스트일 수 있다. 서버 측은 리소스 관리 시스템과 상호 작용하여 네트워크 관리 디바이스 상의 리스트를 획득할 수 있다.
S502. 서버 측은 서버 측과 액티브 클라이언트 사이의 연결이 정상인지를 판단하고, 그렇다면 S503을 수행하거나, 또는 그렇지 않으면, S504를 수행한다.
예를 들면, 이 실시예에서의 정상 연결은 정상적인 통신이 수행될 수 있음을 지시한다. 서버 측은 NETCONF 프로토콜의 해당 컨텐츠를 사용하여 서버 측과 스탠바이 클라이언트 사이의 연결이 정상인지 여부를 판별할 수 있다. 세부 사항은 여기에 설명되어 있지 않다.
S503. 서버 측은 액티브 클라이언트를 타깃 클라이언트로서 판단한 다음, S505를 수행한다.
예를 들어, 서버 측은 도 2 또는 도 3에 대응하는 실시예에서 언급된 클라이언트, 즉 타깃 클라이언트로서 액티브 클라이언트를 선택한다.
S504. 서버 측은 대응관계 및 액티브 클라이언트에 따라 액티브 클라이언트의 스탠바이 클라이언트를 타깃 클라이언트로서 판단한다.
대응관계는 액티브 클라이언트에 대한 정보와 스탠바이 클라이언트에 대한 정보를 포함한다. 대응관계는 네트워크 관리 장치 상의 리스트에 저장될 수도 있거나, 또는 다른 엔트리의 형태로 서버 측에 저장될 수도 있으며, 설명을 위해 예제가 여기에 하나씩 제공되지 않는다.
예를 들어, 서버 측과 스탠바이 클라이언트 사이의 연결이 정상이라고 판단한 후에, 서버 측은 도 2 또는 도 3에 대응하는 실시예에서 언급된 클라이언트, 즉 타깃 클라이언트로서 스탠바이 클라이언트를 선택한다. 서버 측과 스탠바이 클라이언트 사이의 연결이 정상인지를 판단하기 위해 서버 측에 의해 사용되는 방법은 S502에서의 방법과 동일하다. 세부 사항은 여기에서 다시 설명되지 않는다.
S505. 서버 측은 획득 메시지를 획득한다.
예를 들어, 획득 메시지는 페치(fetch) 메시지일 수 있다. 페치 메시지는 NETCONF 프로토콜, RESTCONF 프로토콜, 또는 구성 기능을 구현하는 다른 프로토콜에 기초하는 메시지일 수 있다. 페치 메시지는 서버 측에 의해 요청된 리소스에 관한 정보를 포함한다. 서버 측에 의해 요청된 리소스에 관한 정보의 구체적인 형태에 대해서, S201을 참조한다.
S505는 S502 내지 S504 이전에 수행될 수 있고, 이 실시예에서 순서가 제한되지 않는다.
S506. 서버 측은 획득 메시지를 타깃 클라이언트에 송신한다.
서버 측은 NETCONF 프로토콜의 규정에 기초하여 클라이언트에 페치 메시지를 송신할 수 있다. 세부 사항은 여기에 설명되어 있지 않다.
S507. 획득 메시지를 수신한 후, 타깃 클라이언트는 응답 메시지를 생성한다.
예를 들어, 응답 메시지는 페치 응답 메시지일 수 있다. 페치-응답 메시지는 NETCONF 프로토콜, RESTCONF 프로토콜, 또는 구성 기능을 구현하는 다른 프로토콜에 기초하는 메시지일 수 있다. 페치-응답 메시지는 서버 측에 할당된 리소스에 관한 정보를 포함한다. 구체적인 형식에 대해서, S203의 설명을 참조한다.
S508. 타깃 클라이언트는 페치-응답 메시지를 서버 측에 송신한다.
타깃 클라이언트는 NETCONF 프로토콜의 규정에 기초하여 서버 측에 페치-응답 메시지를 송신할 수 있다. 세부 사항은 여기에 설명되어 있지 않다.
이 실시예에서의 페치 메시지 및 페치-응답 메시지의 예는 다음과 같다.
<fetch message-id=101> //페치 식별자 요청 메시지, 메시지의 식별자는 101이다
<data>
<address-pool operation="GET"> //리소스 명칭은 어드레스 풀이고, 액션 유형은 "요청"(GET)이다
<address-number>254</address-number> //요청된 어드레스의 수량은 254이다
</address-pool>
</data>
</fetch>
<fetch-reply message-id=101> //"페치-응답"은 요청 응답 메시지를 식별하고, 메시지의 식별자는 101이다
<data>
<address-pool> //리소스 명칭은 어드레스 풀이다
<address-pool-entry>
<name>First_pool</name> //어드레스 풀의 명칭
<ip-lower-address>100.0.0.1</ip-lower-address>
<ip-upper-address>100.0.0.254</ip-lower-address>
<life-time>24H</life-time> //어드레스 풀의 유효 기간은 24 시간이다
</address-pool-entry>
</address-pool>
</data>
</fetch-reply>.
전술한 프로세스로부터, 이 실시예에서, 서버 측과 클라이언트 사이의 리소스 구성을 수행하는 처리를 수행하기 위해, 페치 메시지와 페치-응답 메시지는 모두 NETCONF 프로토콜, RESTCONF 프로토콜, 또는 구성 기능을 구현하는 다른 프로토콜의 프레임워크 내에서 새롭게 설정된 메시지 유형인 것을 알 수 있다.
또한, 이 실시예에서, 액티브 클라이언트 및 스탠바이 클라이언트가 존재하면, 서버 측은 하나의 클라이언트에만 요청 메시지를 송신하므로, 전송 리소스가 감소될 수 있다.
본원의 실시예는 서버 측으로서 사용되는 장치 및 클라이언트로서 사용되는 장치를 더 개시한다. 서버 측으로서 사용되는 장치는 도 2, 도 3, 또는 도 5에 도시된 방법에서 "서버 측"에 의해 수행되는 단계들을 구현할 수 있고, 클라이언트로서 사용되는 장치는 도 2, 도 3, 또는 도 5에 도시된 방법에서 "클라이언트"에 의해 수행되는 단계들을 구현할 수 있다. 서버 측으로서 사용되는 장치는 도 2, 도 3, 또는 도 5에 도시된 방법을 사용하여, 클라이언트로서 사용되는 장치로부터 리소스를 획득할 수 있다.
도 6에 도시된 바와 같이, 서버 측으로서 사용되는 장치는 획득 모듈(601), 송신 모듈(602), 및 수신 모듈(603)을 포함한다.
획득 모듈(601)은 리소스 요청을 획득하도록 구성되며, 리소스 요청은 클라이언트로서 사용되는 장치의 어드레스 및 서버 측으로서 사용되는 장치에 의해 요청된 리소스에 관한 정보를 포함한다. 송신 모듈(602)은 클라이언트로서 사용되는 장치의 어드레스에 따라 클라이언트로서 사용되는 장치에 리소스 요청을 송신하도록 구성된다. 수신 모듈(603)은 클라이언트로서 사용되는 장치에 의해 송신된 리소스 응답을 수신하도록 구성되고, 리소스 응답은 서버 측으로서 사용되는 장치에 할당된 리소스에 관한 정보를 포함한다.
선택적으로, 도 6에 도시된 장치는, 서버 측으로서 사용되는 장치에 의해 사용되는 리소스가 조건을 만족하는지를 판단하도록 구성된 판단 모듈(604)을 더 포함할 수 있고, 여기서 조건은 서버 측으로서 사용되는 장치의 리소스 사용 상황을 나타내는 데 사용된다.
선택적으로, 판단 모듈이 판단 결과를 획득하면, 획득 모듈(601)은 다음의 특정 구현, 서버 측으로서 사용되는 장치에 의해 사용되는 리소스가 조건을 만족한다고 판단하는 때, 서버 측으로서 사용되는 장치 및 조건에 따라 리소스 요청을 생성하는 단계에서 리소스 요청을 획득한다.
선택적으로, 도 6에 도시된 장치는, 제1 송신 모듈이 클라이언트로서 사용되는 장치에 리소스 요청을 송신하기 전에, 서버 측으로서 사용되는 장치와 클라이언트로서 사용되는 액티브 장치 사이의 통신이 정상이라고 판단하는 때, 클라이언트로서 사용되는 액티브 장치를 클라이언트로서 사용되는 장치로서 선택하도록 구성된 제1 선택 모듈(605)을 더 포함할 수 있다.
선택적으로, 도 6에 도시된 장치는, 제1 송신 모듈이 클라이언트로서 사용되는 장치에 리소스 요청을 송신하기 전에, 서버 측으로서 사용되는 장치와 클라이언트로서 사용되는 액티브 장치 사이의 통신이 비정상이라고 판단하는 때, 대응관계 및 클라이언트로서 사용되는 액티브 장치에 따라, 클라이언트로서 사용되는 스탠바이 장치를 클라이언트로서 사용되는 장치로서 선택하도록 구성된 제2 선택 모듈(606)을 더 포함할 수 있고, 여기서 대응관계는 클라이언트로서 사용되는 액티브 장치에 관한 정보 및 클라이언트로서 사용되는 스탠바이 장치에 관한 정보를 포함한다.
선택적으로, 획득 모듈(601)에 의해 획득된 리소스 요청은 네트워크 구성(NETCONF) 프로토콜에 기초한 통지(notification) 메시지이고, 통지 메시지는 서버 측으로서 사용되는 장치에 의해 요청된 리소스에 관한 정보를 포함한다. 수신 모듈(603)에 의해 수신된 리소스 응답은 NETCONF 프로토콜에 기초한 RPC 메시지를 포함하고, RPC 메시지는 서버 측으로서 사용되는 장치에 할당된 리소스에 관한 정보를 포함한다.
대안적으로, 획득 모듈(601)에 의해 획득된 리소스 요청은 RESTCONF 프로토콜에 기초한 통지 메시지이고, 통지 메시지는 서버 측으로서 사용되는 장치에 의해 요청된 리소스에 관한 정보를 포함한다. 수신 모듈(603)에 의해 수신된 리소스 응답은 RESTCONF 프로토콜에 기초한 포스트(post) 메시지이고, 포스트 메시지는 서버 측으로서 사용되는 장치에 할당된 리소스에 관한 정보를 포함한다.
대안적으로, 획득 모듈(601)에 의해 획득된 리소스 요청은 획득 메시지이고, 획득 메시지는 서버 측으로서 사용되는 장치에 의해 요청된 리소스에 관한 정보를 포함한다. 수신 모듈(603)에 의해 수신된 리소스 응답은 응답 메시지이고, 응답 메시지는 서버 측으로서 사용되는 장치에 할당된 리소스에 관한 정보를 포함하며, 응답 메시지는 획득 메시지에 응답하는 데 사용된다.
선택적으로, 서버 측으로서 사용되는 장치에 의해 요청된 리소스에 관한 정보로서, 획득 모듈(601)에 의해 획득된 리소스 요청에 포함되어 있는 정보는 제1 액션 유형 및 서버 측으로서 사용되는 장치에 의해 요청된 리소스의 파라미터를 포함하고, 제1 액션 유형은 서버 측으로서 사용되는 장치에 의해 요청된 리소스에 대해 수행된 동작을 나타내는 데 사용된다. 서버 측으로서 사용되는 장치에 할당된 리소스에 관한 정보로서, 수신 모듈(603)에 의해 수신된 리소스 응답에 포함되어 있는 정보는 제2 액션 유형 및 서버 측으로서 사용되는 장치에 할당된 리소스의 파라미터를 포함하고, 제2 액션 유형은 서버 측으로서 사용되는 장치에 할당된 리소스에 대해 수행된 동작을 나타내는데 사용된다.
대안적으로, 서버 측으로서 사용되는 장치에 의해 요청된 리소스에 관한 정보로서, 획득 모듈(601)에 의해 획득된 리소스 요청에 포함되어 있는 정보는 제1 액션 유형, 제1 식별자, 및 서버 측으로 사용되는 장치에 의해 요청된 리소스의 파라미터를 포함하고, 제1 액션 유형은 서버 측으로서 사용되는 장치에 의해 요청된 리소스에 대해 수행된 동작을 나타내는 데 사용되며, 제1 식별자는 리소스 요청의 순서를 나타내는 데 사용된다. 서버 측으로서 사용되는 장치에 할당된 리소스에 관한 정보로서, 수신 모듈(603)에 의해 수신된 리소스 응답에 포함되어 있는 정보는 제2 식별자 및 서버 측으로서 사용되는 장치에 할당된 리소스의 파라미터를 포함하며, 제2 식별자는 리소스 응답의 순서를 나타내는 데 사용되고, 제2 식별자는 제1 식별자에 대응한다.
이 실시예에서 서버 측으로서 사용되는 장치는 클라이언트로서 사용되는 장치에 리소스 요청을 능동적으로 송신하여 리소스 구성을 요청함으로써, 리소스 낭비를 감소시키는 것을 돕는다.
도 7에 도시된 바와 같이, 클라이언트로서 사용되는 장치는 수신 모듈(701), 획득 모듈(702), 및 송신 모듈(703)을 포함한다.
수신 모듈(701)은 서버 측으로서 사용되는 장치에 의해 송신된 리소스 요청을 수신하도록 구성되며, 리소스 요청은 클라이언트로서 사용되는 장치의 어드레스 및 서버 측으로서 사용되는 장치에 의해 요청된 리소스에 관한 정보를 포함한다. 획득 모듈(702)은 서버 측으로서 사용되는 장치에 의해 요청된 리소스에 관한 정보로서, 리소스 요청에 포함되어 있는 정보에 따라, 서버 측으로서 사용되는 장치에 할당된 리소스에 관한 정보를 획득하도록 구성된다. 송신 모듈(703)은 서버 측으로서 사용되는 장치에 리소스 응답을 송신하도록 구성되고, 리소스 응답은 서버 측으로서 사용되는 장치에 할당된 리소스에 관한 정보를 포함한다.
선택적으로, 수신 모듈(701)에 의해 수신된 리소스 요청은 NETCONF 프로토콜에 기초한 통지 메시지이고, 통지 메시지는 서버 측으로서 사용되는 장치에 의해 요청된 리소스에 관한 정보를 포함한다. 송신 모듈(703)에 의해 송신된 리소스 응답은 NETCONF 프로토콜에 기초한 메시지이고, RPC 메시지는 서버 측으로서 사용되는 장치에 할당된 리소스에 관한 정보를 포함한다.
대안적으로, 수신 모듈(701)에 의해 수신된 리소스 요청은 RESTCONF 프로토콜에 기초한 통지 메시지이고, 통지 메시지는 서버 측으로서 사용되는 장치에 의해 요청된 리소스에 관한 정보를 포함한다. 송신 모듈(703)에 의해 송신된 리소스 응답은 RESTCONF 프로토콜에 기초하는 포스트 메시지이고, 포스트 메시지는 서버 측으로서 사용되는 장치에 할당된 리소스에 관한 정보를 포함한다.
대안적으로, 수신 모듈(701)에 의해 수신된 리소스 요청은 획득 메시지이고, 획득 메시지는 서버 측으로서 사용되는 장치에 의해 요청된 리소스에 관한 정보를 포함한다. 송신 모듈(703)에 의해 송신된 리소스 응답은 응답 메시지이고, 응답 메시지는 서버 측으로서 사용되는 장치에 할당된 리소스에 관한 정보를 포함하며, 응답 메시지는 획득 메시지에 응답하는 데 사용된다.
선택적으로, 서버 측으로서 사용되는 장치에 의해 요청되는 리소스에 관한 정보로서, 수신 모듈(701)에 의해 수신된 리소스 요청에 포함되어 있는 정보는 제1 액션 유형 및 서버 측으로서 사용되는 장치에 의해 요청된 리소스의 파라미터를 포함하고, 제1 액션 유형은 서버 측으로서 사용되는 장치에 의해 요청된 리소스에 대해 수행된 동작을 나타내는 데 사용된다. 서버 측으로서 사용되는 장치에 할당된 리소스에 관한 정보로서 획득 모듈(702)에 의해 획득된 정보는 제2 액션 유형 및 서버 측으로서 사용되는 장치에 할당된 리소스의 파라미터를 포함하고, 제2 액션 유형은 서버 측으로서 사용되는 장치에 할당된 리소스에 대해 수행된 동작을 나타내는데 사용된다.
대안적으로, 서버 측으로서 사용되는 장치에 의해 요청된 리소스에 관한 정보로서, 수신 모듈(701)에 의해 수신된 리소스 요청에 포함되어 있는 정보는 제1 액션 유형, 제1 식별자, 및 서버 측으로서 사용되는 장치에 의해 요청된 리소스의 파라미터를 포함하고, 제1 액션 유형은 서버 측으로서 사용되는 장치에 의해 요청된 리소스에 대해 수행된 동작을 나타내는 데 사용되며, 제1 식별자는 리소스 요청의 순서를 나타내는 데 사용된다. 서버 측으로서 사용되는 장치에 할당된 리소스에 관한 정보로서, 획득 모듈(702)에 의해 획득된 정보는 제2 식별자 및 서버 측으로서 사용되는 장치에 할당된 리소스의 파라미터를 포함하고, 제2 식별자는 리소스 응답의 순서를 나타내는 데 사용되며, 제2 식별자는 제1 식별자에 대응한다.
도 6의 서버 측으로서 사용되는 장치에 의해 송신된 리소스 요청을 수신한 후, 이 실시예에서 클라이언트로서 사용되는 장치는 서버 측으로서 사용되는 장치에 리소스 응답을 송신하여 서버 측으로서 사용되는 장치에 리소스를 구성하도록 지시함으로써, 리소스 낭비를 방지하도록 돕는다.
도 8에 도시된 바와 같이, 본원의 실시예는 프로세서, 프로세서와 함께 사용되는 메모리, 및 통신 인터페이스를 포함하는, 서버 측으로서 사용되는 장치를 더 개시한다. 전술한 구성 요소는 통신 버스를 사용하여 서로 통신한다. 도 8에 대응하는 실시예에서 제공되는 서버 측으로서 사용되는 장치는, 도 6에 대응하는 실시예에서 제공되는 서버 측으로서 사용되는 장치일 수 있다.
메모리는 리소스 획득 기능을 구현하는 프로그램을 저장하고, 프로세서는 메모리 및 통신 인터페이스에서 프로그램을 호출함으로써, 도 2, 도 3, 또는 도 5에 도시된 방법에서의 "서버 측"에 의해 수행된 컨텐츠를 구현할 수 있다.
본원의 실시예는 클라이언트로서 사용되는 장치를 더 개시하고, 그 구조는 도 9에 도시된다. 메모리는 리소스 획득 기능을 구현하는 프로그램을 저장하고, 프로세서는 메모리 및 통신 인터페이스에서 프로그램을 호출함으로써, 도 2, 도 3, 또는 도 5에 도시된 방법에서의 "클라이언트"에 의해 수행된 컨텐츠를 구현할 수 있다. 도 9에 대응하는 실시예에서 제공되는 클라이언트로서 사용되는 장치는, 도 7에 대응하는 실시예에서 제공되는 클라이언트로서 사용되는 장치일 수 있다.
본원의 실시예들에서 리소스 요청 및 리소스 응답은 YANG 모델을 사용하여 기술될 수 있다. 구체적인 기술 방법은 여기에 설명되지 않습니다.
본 명세서의 실시예들은 모두 점진적인 방식으로 설명된다. 실시예들에서 동일하거나 유사한 부분에 대해서, 이들 실시예를 참조한다. 각 실시예는 다른 실시예들과의 차이점에 주목한다.
전술한 범용 프로세서는 마이크로 프로세서일 수 있거나 또는 프로세서는 임의의 종래 프로세서일 수 있다. 본 발명의 실시예를 참조하여 개시된 방법의 단계들은 하드웨어 프로세서에 의해 직접 수행될 수 있거나, 또는 프로세서 내의 하드웨어 및 소프트웨어 모듈의 조합을 사용하여 수행될 수 있다. 단계들이 소프트웨어를 사용하여 구현되는 때, 전술한 기능들을 구현하는 코드는 컴퓨터 판독가능 매체에 저장될 수 있으며, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체를 포함한다. 저장 매체는 컴퓨터에 액세스 가능한 임의의 이용가능한 매체일 수 있다. 다음은 예제로 사용되었지만 제한되지는 않는다. 컴퓨터 판독 가능 매체는 RAM(random access memory), ROM(read-only memory), EEPROM(electrically erasable programmable read-only memory), CD-ROM(compact disc read-only memory) 또는 다른 광 디스크 스토리지, 디스크 스토리지 매체 또는 다른 디스크 스토리지, 또는 명령 또는 데이터 구조 형태로 프로그램 코드를 갖거나 또는 저장하는 데 사용될 수 있는 매체로서 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체일 수 있다. 컴퓨터 판독가능 매체는 CD(compact disc), 레이저 디스크, DVD(digital video disc), 플로피 디스크, 또는 블루레이(Blu-ray) 디스크일 수 있다.
마지막으로, 전술한 실시예는 본 발명을 제한하는 것 이외에, 본 발명의 기술적 해결책을 설명하기 위해 의도된 예일 뿐이라는 것을 유의해야 한다. 본 발명 및 본 발명의 이점은 상기의 실시예를 참조하여 상세히 설명되기는 하지만, 당업자들은 본 발명의 청구범위의 범주를 벗어나지 않으면서 전술한 실시예에서 설명된 기술적 해결책을 여전히 변경하거나 또는 그것의 일부 기술적 특징에 대한 동등한 대체물을 만들 수 있음을 이해해야 한다.

Claims (32)

  1. 서버 측이, 리소스 요청을 획득하는 단계,
    상기 서버 측이, 클라이언트에 상기 리소스 요청을 송신하는 단계, 그리고
    상기 서버 측이, 상기 클라이언트에 의해 송신된 리소스 응답을 수신하는 단계
    를 포함하고,
    상기 리소스 요청은 상기 서버 측에 의해 요청된 리소스에 관한 정보를 포함하고,
    상기 리소스 응답은 상기 서버 측에 할당된 리소스에 관한 정보를 포함하는,
    리소스 획득 방법
  2. 제1항에 있어서,
    상기 서버 측이 리소스 요청을 획득하기 전에,
    상기 서버 측이 상기 서버 측에 의해 사용된 리소스가 조건을 만족하는지를 판단하는 단계
    를 더 포함하고,
    상기 조건은 상기 서버 측의 리소스 사용 상황을 나타내는 데 사용되는,
    리소스 획득 방법.
  3. 제2항에 있어서,
    상기 서버 측이, 리소스 요청을 획득하는 단계는,
    상기 서버 측에 의해 사용된 리소스가 조건을 만족한다고 판단한 때, 상기 서버 측이, 상기 서버 측에서 사용된 리소스 및 상기 조건에 따라 상기 리소스 요청을 생성하는 단계를 포함하는,
    리소스 획득 방법.
  4. 제1항 내지 제3항 중 어느 한 항에 있어서,
    상기 서버 측이, 상기 클라이언트에 상기 리소스 요청을 송신하기 전에,
    상기 서버 측과 액티브 클라이언트 사이의 통신이 정상이라고 판단하는 때, 상기 서버 측이, 상기 액티브 클라이언트를 상기 클라이언트로서 선택하는 단계를 더 포함하는 리소스 획득 방법.
  5. 제1항 내지 제3항 중 어느 한 항에 있어서,
    상기 서버 측이, 상기 클라이언트에 상기 리소스 요청을 송신하기 전에,
    상기 서버 측과 액티브 클라이언트 사이의 통신이 비정상이라고 판단하는 때, 상기 서버 측이 대응관계 및 상기 액티브 클라이언트에 따라 스탠바이 클라이언트를 상기 클라이언트로서 선택하는 단계를 더 포함하고,
    상기 대응관계는 상기 액티브 클라이언트에 관한 정보 및 상기 스탠바이 클라이언트에 관한 정보를 포함하는,
    리소스 획득 방법.
  6. 제1항 내지 제5항 중 어느 한 항에 있어서,
    상기 리소스 요청은 NETCONF(network configuration) 프로토콜에 기초한 통지(notification) 메시지를 포함하고, 상기 통지 메시지는 상기 서버 측에 의해 요청된 리소스에 관한 정보를 포함하며,
    상기 리소스 응답은 상기 NETCONF 프로토콜에 기초한 RPC(remote procedure call) 메시지를 포함하고, 상기 RPC 메시지는 상기 서버 측에 할당된 리소스에 관한 정보를 포함하는,
    리소스 획득 방법.
  7. 제1항 내지 제5항 중 어느 한 항에 있어서,
    상기 리소스 요청은 RESTCONF 프로토콜에 기초한 통지 메시지를 포함하고, 상기 통지 메시지는 상기 서버 측에 의해 요청된 리소스에 관한 정보를 포함하며,
    상기 리소스 응답은 RESTCONF 프로토콜에 기초한 포스트(post) 메시지를 포함하고, 상기 포스트 메시지는 서버 측에 할당된 리소스에 관한 정보를 포함하는,
    리소스 획득 방법.
  8. 제1항 내지 제5항 중 어느 한 항에 있어서,
    상기 리소스 요청은 획득 메시지를 포함하고, 상기 획득 메시지는 상기 서버 측에 의해 요청된 리소스에 관한 정보를 포함하며,
    상기 리소스 응답은 응답 메시지를 포함하고, 상기 응답 메시지는 서버 측에 할당된 리소스에 관한 정보를 포함하며, 상기 응답 메시지는 상기 획득 메시지에 응답하는 데 사용되는,
    리소스 획득 방법.
  9. 제1항 내지 제8항 중 어느 한 항에 있어서,
    상기 서버 측에 의해 요청된 리소스에 관한 정보는 상기 서버 측에 의해 요청된 리소스의 제1 액션 유형 및 파라미터를 포함하고, 상기 제1 액션 유형은 상기 서버 측에 의해 요청된 리소스에 대해 수행된 동작을 나타내는 데 사용되며,
    상기 서버 측에 할당된 리소스에 관한 정보는 제2 액션 유형 및 서버 측에 할당된 리소스의 파라미터를 포함하고, 상기 제2 액션 유형은 상기 서버 측에 할당된 리소스에 대해 수행된 동작을 나타내는 데 사용되는,
    리소스 획득 방법.
  10. 제1항 내지 제8항 중 어느 한 항에 있어서,
    상기 서버 측에 의해 요청된 리소스에 관한 정보는 제1 액션 유형, 제1 식별자, 및 상기 서버 측에 의해 요청된 리소스의 파라미터를 포함하고, 상기 제1 액션 유형은 상기 서버 측에 의해 요청된 리소스에 대해 수행된 동작을 나타내는 데 사용되며, 상기 제1 식별자는 상기 리소스 요청의 순서를 나타내는 데 사용되고,
    상기 서버 측에 할당된 리소스에 관한 정보는 제2 식별자 및 상기 서버 측에 할당된 리소스의 파라미터를 포함하고, 상기 제2 식별자는 리소스 응답의 순서를 나타내는 데 사용되며, 상기 제2 식별자는 상기 제1 식별자에 대응하는,
    리소스 획득 방법.
  11. 클라이언트가, 서버 측에 의해 송신된 리소스 요청을 수신하는 단계 - 상기 리소스 요청은 상기 서버 측에 의해 요청된 리소스에 관한 정보를 포함함 -,
    상기 클라이언트가, 상기 서버 측에 의해 요청된 리소스에 관한 정보로서 상기 리소스 요청 내에 포함된 정보에 따라, 상기 서버 측에 할당된 리소스에 관한 정보를 획득하는 단계, 그리고
    상기 클라이언트가, 상기 서버 측에 리소스 응답을 송신하는 단계
    를 포함하고,
    상기 리소스 응답은 상기 서버 측에 할당된 리소스에 관한 정보를 포함하는,
    리소스 획득 방법.
  12. 제11항에 있어서,
    상기 리소스 요청은 NETCONF(network configuration) 프로토콜에 기초한 통지(notification) 메시지를 포함하고, 상기 통지 메시지는 상기 서버 측에 의해 요청된 리소스에 관한 정보를 포함하며,
    상기 리소스 응답은 상기 NETCONF 프로토콜에 기초한 RPC(remote procedure call) 메시지를 포함하고, 상기 RPC 메시지는 상기 서버 측에 할당된 리소스에 관한 정보를 포함하는,
    리소스 획득 방법.
  13. 제11항에 있어서,
    상기 리소스 요청은 RESTCONF 프로토콜에 기초한 통지 메시지를 포함하고, 상기 통지 메시지는 상기 서버 측에 의해 요청된 리소스에 관한 정보를 포함하며,
    상기 리소스 응답은 상기 RESTCONF 프로토콜에 기초한 포스트(post) 메시지를 포함하고, 상기 포스트 메시지는 상기 서버 측에 할당된 리소스에 관한 정보를 포함하는,
    리소스 획득 방법.
  14. 제11항에 있어서,
    상기 리소스 요청은 획득 메시지를 포함하고, 상기 획득 메시지는 상기 서버 측에 의해 요청된 리소스에 관한 정보를 포함하며,
    상기 리소스 응답은 응답 메시지를 포함하고, 상기 응답 메시지는 서버 측에 할당된 리소스에 관한 정보를 포함하며, 상기 응답 메시지는 상기 획득 메시지에 응답하는 데 사용되는,
    리소스 획득 방법.
  15. 제11항 내지 제14항 중 어느 한 항에 있어서,
    상기 서버 측에 의해 요청된 리소스에 관한 정보는 상기 서버 측에 의해 요청된 리소스의 제1 액션 유형 및 파라미터를 포함하고, 상기 제1 액션 유형은 상기 서버 측에 의해 요청된 리소스에 대해 수행된 동작을 나타내는 데 사용되며,
    상기 서버 측에 할당된 리소스에 관한 정보는 제2 액션 유형 및 서버 측에 할당된 리소스의 파라미터를 포함하고, 상기 제2 액션 유형은 상기 서버 측에 할당된 리소스에 대해 수행된 동작을 나타내는 데 사용되는,
    리소스 획득 방법.
  16. 제11항 내지 제14항 중 어느 한 항에 있어서,
    상기 서버 측에 의해 요청된 리소스에 관한 정보는 제1 액션 유형, 제1 식별자, 및 상기 서버 측에 의해 요청된 리소스의 파라미터를 포함하고, 상기 제1 액션 유형은 상기 서버 측에 의해 요청된 리소스에 대해 수행된 동작을 나타내는 데 사용되며, 상기 제1 식별자는 상기 리소스 요청의 순서를 나타내는 데 사용되고,
    상기 서버 측에 할당된 리소스에 관한 정보는 제2 식별자 및 상기 서버 측에 할당된 리소스의 파라미터를 포함하고, 상기 제2 식별자는 리소스 응답의 순서를 나타내는 데 사용되며, 상기 제2 식별자는 상기 제1 식별자에 대응하는,
    리소스 획득 방법.
  17. 서버 측으로서 사용되는 장치로서,
    리소스 요청을 획득하도록 구성된 획득 모듈,
    클라이언트로서 사용되는 장치에 상기 리소스 요청을 송신하도록 구성된 송신 모듈, 그리고
    클라이언트로서 사용되는 장치에 의해 송신된 리소스 응답을 수신하도록 구성된 수신 모듈
    을 포함하고, 상기 리소스 요청은 서버 측으로서 사용되는 상기 장치에 의해 요청된 리소스에 관한 정보를 포함하고,
    상기 리소스 응답은 상기 서버 측으로서 사용되는 상기 장치에 할당된 리소스에 관한 정보를 포함하는,
    장치.
  18. 제17항에 있어서,
    서버 측으로서 사용되는 상기 장치에 의해 사용된 리소스가 조건을 만족하는지를 판단하도록 구성된 판단 모듈을 더 포함하고,
    상기 조건은 상기 서버 측의 리소스 사용 상황을 나타내는 데 사용되는,
    장치.
  19. 제18항에 있어서,
    상기 제1 획득 모듈은 구체적으로, 서버 측으로서 사용되는 상기 장치에 의해 사용된 리소스가 조건을 만족한다고 판단한 때, 서버 측으로서 사용되는 상기 장치에서 사용된 리소스 및 상기 조건에 따라 상기 리소스 요청을 생성하도록 구성된,
    장치.
  20. 제17항 내지 제19항 중 어느 한 항에 있어서,
    상기 제1 송신 모듈이, 클라이언트로서 사용되는 상기 장치에 상기 리소스 요청을 송신하기 전에, 서버 측으로서 사용되는 상기 장치와 클라이언트로서 사용되는 액티브 장치 사이의 통신이 정상이라고 판단하는 때, 서버 측으로서 사용되는 상기 장치가, 상기 액티브 장치를 클라이언트로서 사용되는 상기 장치로서 선택하도록 구성된 제1 선택 모듈을 더 포함하는 장치.
  21. 제17항 내지 제19항 중 어느 한 항에 있어서,
    상기 제1 송신 모듈이, 클라이언트로서 사용되는 상기 장치에 상기 리소스 요청을 송신하기 전에, 서버 측으로서 사용되는 상기 장치와 클라이언트로서 사용되는 액티브 장치 사이의 통신이 비정상이라고 판단한 때, 대응관계 및 클라이언트로서 사용되는 상기 액티브 장치에 따라 클라이언트로서 사용되는 스탠바이 장치를 클라이언트로서 사용되는 상기 장치로서 선택하도록 구성된 제2 선택 모듈을 더 포함하고,
    상기 대응관계는 클라이언트로서 사용되는 상기 액티브 장치에 관한 정보 및 클라이언트로서 사용되는 상기 스탠바이 장치에 관한 정보를 포함하는,
    장치.
  22. 제17항 내지 제21항 중 어느 한 항에 있어서,
    상기 리소스 요청은 NETCONF(network configuration) 프로토콜에 기초한 통지(notification) 메시지를 포함하고, 상기 통지 메시지는 서버 측으로서 사용되는 상기 장치에 의해 요청된 리소스에 관한 정보를 포함하며,
    상기 리소스 응답은 상기 NETCONF 프로토콜에 기초한 RPC(remote procedure call) 메시지를 포함하고, 상기 RPC 메시지는 서버 측으로서 사용되는 상기 장치에 할당된 리소스에 관한 정보를 포함하는,
    장치.
  23. 제17항 내지 제21항 중 어느 한 항에 있어서,
    상기 리소스 요청은 RESTCONF 프로토콜에 기초한 통지 메시지를 포함하고, 상기 통지 메시지는 서버 측으로서 사용되는 상기 장치에 의해 요청된 리소스에 관한 정보를 포함하며,
    상기 리소스 응답은 RESTCONF 프로토콜에 기초한 포스트(post) 메시지를 포함하고, 상기 포스트 메시지는 서버 측으로서 사용되는 상기 장치에 할당된 리소스에 관한 정보를 포함하는,
    장치.
  24. 제17항 내지 제21항 중 어느 한 항에 있어서,
    상기 리소스 요청은 획득 메시지를 포함하고, 상기 획득 메시지는 서버 측으로서 사용되는 상기 장치에 의해 요청된 리소스에 관한 정보를 포함하며,
    상기 리소스 응답은 응답 메시지를 포함하고, 상기 응답 메시지는 서버 측으로서 사용되는 장치에 할당된 리소스에 관한 정보를 포함하며, 상기 응답 메시지는 상기 획득 메시지에 응답하는 데 사용되는,
    장치.
  25. 제17항 내지 제24항 중 어느 한 항에 있어서,
    서버 측으로서 사용되는 상기 장치에 의해 요청된 리소스에 관한 정보는 서버 측으로서 사용되는 상기 장치에 의해 요청된 리소스의 제1 액션 유형 및 파라미터를 포함하고, 상기 제1 액션 유형은 서버 측으로서 사용되는 상기 장치에 의해 요청된 리소스에 대해 수행된 동작을 나타내는 데 사용되며,
    서버 측으로서 사용되는 상기 장치에 할당된 리소스에 관한 정보는 제2 액션 유형 및 서버 측으로서 사용되는 장치에 할당된 리소스의 파라미터를 포함하고, 상기 제2 액션 유형은 서버 측으로서 사용되는 상기 장치에 할당된 리소스에 대해 수행된 동작을 나타내는 데 사용되는,
    장치.
  26. 제17항 내지 제24항 중 어느 한 항에 있어서,
    서버 측으로서 사용되는 상기 장치에 의해 요청된 리소스에 관한 정보는 제1 액션 유형, 제1 식별자, 및 서버 측으로서 사용되는 상기 장치에 의해 요청된 리소스의 파라미터를 포함하고, 상기 제1 액션 유형은 서버 측으로서 사용되는 상기 장치에 의해 요청된 리소스에 대해 수행된 동작을 나타내는 데 사용되며, 상기 제1 식별자는 상기 리소스 요청의 순서를 나타내는 데 사용되고,
    서버 측으로서 사용되는 상기 장치에 할당된 리소스에 관한 정보는 제2 식별자 및 서버 측으로서 사용되는 상기 장치에 할당된 리소스의 파라미터를 포함하고, 상기 제2 식별자는 리소스 응답의 순서를 나타내는 데 사용되며, 상기 제2 식별자는 상기 제1 식별자에 대응하는,
    리소스 획득 방법.
  27. 클라이언트로서 사용되는 장치로서,
    서버 측으로서 사용되는 장치에 의해 송신된 리소스 요청을 수신하도록 구성된 수신 모듈 - 상기 리소스 요청은 서버 측으로서 사용되는 상기 장치에 의해 요청된 리소스에 관한 정보를 포함함 -,
    서버 측으로서 사용되는 상기 장치에 의해 요청된 리소스에 관한 정보로서 상기 리소스 요청 내에 포함된 정보에 따라, 서버 측으로서 사용되는 상기 장치에 할당된 리소스에 관한 정보를 획득하도록 구성된 획득 모듈, 그리고
    서버 측으로서 사용되는 상기 장치에 리소스 응답을 송신하도록 구성된 송신 모듈
    을 포함하고,
    상기 리소스 응답은 서버 측으로서 사용되는 상기 장치에 할당된 리소스에 관한 정보를 포함하는,
    장치.
  28. 제27항에 있어서,
    상기 리소스 요청은 NETCONF(network configuration) 프로토콜에 기초한 통지(notification) 메시지를 포함하고, 상기 통지 메시지는 서버 측으로서 사용되는 상기 장치에 의해 요청된 리소스에 관한 정보를 포함하며,
    상기 리소스 응답은 상기 NETCONF 프로토콜에 기초한 RPC(remote procedure call) 메시지를 포함하고, 상기 RPC 메시지는 서버 측으로서 사용되는 상기 장치에 할당된 리소스에 관한 정보를 포함하는,
    장치.
  29. 제27항에 있어서,
    상기 리소스 요청은 RESTCONF 프로토콜에 기초한 통지 메시지를 포함하고, 상기 통지 메시지는 서버 측으로서 사용되는 상기 장치에 의해 요청된 리소스에 관한 정보를 포함하며,
    상기 리소스 응답은 상기 RESTCONF 프로토콜에 기초한 포스트(post) 메시지를 포함하고, 상기 포스트 메시지는 서버 측으로서 사용되는 상기 장치에 할당된 리소스에 관한 정보를 포함하는,
    장치.
  30. 제27항에 있어서,
    상기 리소스 요청은 획득 메시지를 포함하고, 상기 획득 메시지는 서버 측으로서 사용되는 상기 장치에 의해 요청된 리소스에 관한 정보를 포함하며,
    상기 리소스 응답은 응답 메시지를 포함하고, 상기 응답 메시지는 서버 측으로서 사용되는 장치에 할당된 리소스에 관한 정보를 포함하며, 상기 응답 메시지는 상기 획득 메시지에 응답하는 데 사용되는,
    장치.
  31. 제27항 내지 제30항 중 어느 한 항에 있어서,
    서버 측으로서 사용되는 상기 장치에 의해 요청된 리소스에 관한 정보는 서버 측으로서 사용되는 상기 장치에 의해 요청된 리소스의 제1 액션 유형 및 파라미터를 포함하고, 상기 제1 액션 유형은 서버 측으로서 사용되는 상기 장치에 의해 요청된 리소스에 대해 수행된 동작을 나타내는 데 사용되며,
    서버 측으로서 사용되는 상기 장치에 할당된 리소스에 관한 정보는 제2 액션 유형 및 서버 측으로서 사용되는 장치에 할당된 리소스의 파라미터를 포함하고, 상기 제2 액션 유형은 서버 측으로서 사용되는 상기 장치에 할당된 리소스에 대해 수행된 동작을 나타내는 데 사용되는,
    장치.
  32. 제27항 내지 제30항 중 어느 한 항에 있어서,
    서버 측으로서 사용되는 상기 장치에 의해 요청된 리소스에 관한 정보는 제1 액션 유형, 제1 식별자, 및 서버 측으로서 사용되는 상기 장치에 의해 요청된 리소스의 파라미터를 포함하고, 상기 제1 액션 유형은 서버 측으로서 사용되는 상기 장치에 의해 요청된 리소스에 대해 수행된 동작을 나타내는 데 사용되며, 상기 제1 식별자는 상기 리소스 요청의 순서를 나타내는 데 사용되고,
    서버 측으로서 사용되는 상기 장치에 할당된 리소스에 관한 정보는 제2 식별자 및 서버 측으로서 사용되는 상기 장치에 할당된 리소스의 파라미터를 포함하고, 상기 제2 식별자는 리소스 응답의 순서를 나타내는 데 사용되며, 상기 제2 식별자는 상기 제1 식별자에 대응하는,
    장치.
KR1020187014164A 2015-10-23 2016-10-19 리소스 획득 방법 및 장치 Active KR102128356B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201510697563.5 2015-10-23
CN201510697563.5A CN106612196B (zh) 2015-10-23 2015-10-23 获取资源的方法及装置
PCT/CN2016/102599 WO2017067464A1 (zh) 2015-10-23 2016-10-19 获取资源的方法及装置

Publications (2)

Publication Number Publication Date
KR20180070677A true KR20180070677A (ko) 2018-06-26
KR102128356B1 KR102128356B1 (ko) 2020-07-08

Family

ID=58556727

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020187014164A Active KR102128356B1 (ko) 2015-10-23 2016-10-19 리소스 획득 방법 및 장치

Country Status (6)

Country Link
US (1) US10979360B2 (ko)
EP (1) EP3358785B1 (ko)
JP (2) JP6896722B2 (ko)
KR (1) KR102128356B1 (ko)
CN (1) CN106612196B (ko)
WO (1) WO2017067464A1 (ko)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7302603B2 (ja) * 2018-08-29 2023-07-04 日本電気株式会社 通信装置、方法、及びプログラム
CN112688794A (zh) * 2019-10-18 2021-04-20 华为技术有限公司 Yang模型的管理方法、装置、系统、设备及存储介质
CN112887113A (zh) * 2019-11-29 2021-06-01 华为技术有限公司 处理数据的方法、装置及系统
CN113014411B (zh) * 2019-12-20 2022-11-22 华为技术有限公司 管理网络设备的方法、设备和系统
US11121989B1 (en) * 2020-05-29 2021-09-14 Bank Of America Corporation Centralized repository and communication system for cross-network interactions
US11757833B2 (en) 2021-09-29 2023-09-12 Juniper Networks, Inc. Network device interface for supporting centralized address pool management

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050114492A1 (en) * 2003-10-31 2005-05-26 Peter Arberg DHCP proxy in a subscriber environment
US20100082779A1 (en) * 2008-09-30 2010-04-01 Samsung Electronics Co., Ltd. Method of allocating ip address of image forming apparatus using dhcp, image forming apparatus and system of allocating ip address using dhcp

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6535918B1 (en) * 1998-09-22 2003-03-18 Qualcomm Incorporated Interface between standard terminal equipment unit and high speed wireless link
US6374295B2 (en) * 1998-10-29 2002-04-16 Nortel Networks Limited Active server management
US6449267B1 (en) * 1999-02-24 2002-09-10 Hughes Electronics Corporation Method and apparatus for medium access control from integrated services packet-switched satellite networks
JP3447687B2 (ja) * 2000-10-13 2003-09-16 日本電気株式会社 無線ネットワークシステム及びネットワークアドレス割当方法
US7305375B2 (en) * 2003-04-23 2007-12-04 Hewlett-Packard Development Company, L.P. Method and system for distributed remote resources
JP4093483B2 (ja) * 2003-12-26 2008-06-04 インターナショナル・ビジネス・マシーンズ・コーポレーション 解析システム、解析方法、解析プログラム、及び記録媒体
US7644410B1 (en) * 2004-11-23 2010-01-05 Hewlett-Packard Development Company, L.P. Resource management for shared computing environment
US8285875B2 (en) * 2009-01-28 2012-10-09 Juniper Networks, Inc. Synchronizing resource bindings within computer network
US8335171B1 (en) * 2009-09-29 2012-12-18 Juniper Networks, Inc. NETCONF-enabled provisioning in rollback agnostic environment
US20110078014A1 (en) * 2009-09-30 2011-03-31 Google Inc. Online resource assignment
WO2013025428A2 (en) * 2011-08-12 2013-02-21 School Improvement Network, Llc Prescription of electronic resources based on observational assessments
US9009317B2 (en) * 2011-10-10 2015-04-14 Verizon Patent And Licensing Inc. System for and method of managing network resources
CN102594933B (zh) * 2011-12-20 2015-04-08 华为技术有限公司 一种公网地址分配的方法、装置及系统
CN102664971B (zh) * 2012-04-11 2016-02-10 中兴通讯股份有限公司 网络地址资源管理方法、系统及外部地址资源服务器
CN103780483A (zh) 2012-10-26 2014-05-07 中兴通讯股份有限公司 一种物联网终端设备的资源信息获取方法、系统及设备
JP6171445B2 (ja) * 2013-03-21 2017-08-02 富士通株式会社 割当装置及び割当プログラム
US9258132B2 (en) * 2013-06-06 2016-02-09 Alcatel Lucent NETCONF SNMP gateway
CN104348928B (zh) * 2013-07-31 2019-03-26 华为技术有限公司 一种分配地址资源的方法、管理设备、请求设备及系统
US20160197831A1 (en) * 2013-08-16 2016-07-07 Interdigital Patent Holdings, Inc. Method and apparatus for name resolution in software defined networking
US20150281947A1 (en) * 2014-03-26 2015-10-01 Qualcomm Incorporated Method and apparatus for fast ip address assignment

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050114492A1 (en) * 2003-10-31 2005-05-26 Peter Arberg DHCP proxy in a subscriber environment
US20100082779A1 (en) * 2008-09-30 2010-04-01 Samsung Electronics Co., Ltd. Method of allocating ip address of image forming apparatus using dhcp, image forming apparatus and system of allocating ip address using dhcp

Also Published As

Publication number Publication date
EP3358785A1 (en) 2018-08-08
JP6896722B2 (ja) 2021-06-30
US10979360B2 (en) 2021-04-13
JP2018533872A (ja) 2018-11-15
JP2020109996A (ja) 2020-07-16
CN106612196B (zh) 2019-02-01
JP7207827B2 (ja) 2023-01-18
US20180241689A1 (en) 2018-08-23
KR102128356B1 (ko) 2020-07-08
EP3358785A4 (en) 2018-08-15
EP3358785B1 (en) 2023-07-26
WO2017067464A1 (zh) 2017-04-27
CN106612196A (zh) 2017-05-03

Similar Documents

Publication Publication Date Title
KR102128356B1 (ko) 리소스 획득 방법 및 장치
US8250184B2 (en) System, network entities and computer programs for configuration management of a dynamic host configuration protocol framework
US9210124B2 (en) Method, apparatus, and system for allocating public IP address
US8355395B2 (en) Controlling registration floods in VoIP networks via DNS
EP2611107B1 (en) Verification of cryptographically generated address
EP3709664A1 (en) Stream pushing method, system and server
EP3255866B1 (en) Internet protocol address allocation method and router
CN103535015B (zh) 公网地址资源的管理方法、端口控制协议服务器及客户端
EP2704403A1 (en) Method and device for controlling address configuration manner
JP2022511355A (ja) バルクサブスクリプションのフィルタ
KR20110008311A (ko) 네트워크를 관리하는 방법들 및 디바이스들
EP3048756B1 (en) Management method and apparatus for dynamic host configuration protocol server and relay
CN107360095B (zh) 基于客户端主机名称的端口转发在路由器中的实现方法
CN104683490B (zh) 互联网协议地址的回收方法和装置
CN106034166B (zh) 一种局域网的网络参数配置方法及装置
US20110235641A1 (en) Communication apparatus, method of controlling the communication apparatus,and program
JP6176247B2 (ja) 通信維持システム、端末装置、通信維持方法、および、接続維持プログラム
JP6147415B2 (ja) ネットワークの変化に耐性のある、コンピュータネットワーク内のサービスディスカバリ方法
CN102413205A (zh) 一种ip地址分配方法及相关中继设备、服务器和系统
KR101393017B1 (ko) Nat 환경의 대량 단말 제어를 위한 홀 펀칭 분산 처리 시스템 및 그 시스템의 제어 방법
CN103825974B (zh) Dhcp续约处理方法及装置
WO2015177924A1 (ja) 通信装置及び通信方法及びプログラム
HK1190535B (en) Method of establishing a network socket with a data server

Legal Events

Date Code Title Description
A201 Request for examination
PA0105 International application

Patent event date: 20180518

Patent event code: PA01051R01D

Comment text: International Patent Application

PA0201 Request for examination

Patent event code: PA02012R01D

Patent event date: 20180518

Comment text: Request for Examination of Application

PG1501 Laying open of application
E902 Notification of reason for refusal
PE0902 Notice of grounds for rejection

Comment text: Notification of reason for refusal

Patent event date: 20190918

Patent event code: PE09021S01D

E701 Decision to grant or registration of patent right
PE0701 Decision of registration

Patent event code: PE07011S01D

Comment text: Decision to Grant Registration

Patent event date: 20200327

GRNT Written decision to grant
PR0701 Registration of establishment

Comment text: Registration of Establishment

Patent event date: 20200624

Patent event code: PR07011E01D

PR1002 Payment of registration fee

Payment date: 20200624

End annual number: 3

Start annual number: 1

PG1601 Publication of registration
PR1001 Payment of annual fee

Payment date: 20230518

Start annual number: 4

End annual number: 4

PR1001 Payment of annual fee

Payment date: 20240522

Start annual number: 5

End annual number: 5