KR101578626B1

KR101578626B1 - 컨트롤러와 네트워크 장치 간에 번들 명령을 처리하는 방법

Info

Publication number: KR101578626B1
Application number: KR1020140161070A
Authority: KR
Inventors: 안태진; 김형수; 조성수; 이세희; 한경아
Original assignee: 주식회사 케이티
Priority date: 2013-11-18
Filing date: 2014-11-18
Publication date: 2015-12-17
Also published as: KR20150058061A

Abstract

컨트롤러와 복수의 네트워크 장치 간에 번들 명령을 처리하는 방법이 개시된다. 번들 명령을 처리하는 방법은, 소프트웨어 정의 네트워킹에서 번들 명령을 처리하는 방법에 있어서, 컨트롤러가 적어도 하나의 네트워크 장치에 등록된 번들 명령에 대한 상태 확인 요청을 하는 단계와; 적어도 하나의 네트워크 장치가 상태 확인 요청에 따라 등록된 번들 명령의 상태를 확인하여 컨트롤러로 등록된 번들 명령에 대한 상태 확인 응답을 하는 단계와; 컨트롤러가 상태 확인 응답에 기반하여 등록된 번들 명령의 동일 여부를 판단하여 등록된 번들 명령을 처리하는 단계를 포함한다. 따라서, 컨트롤러와 네트워크 장치간 번들 명령 불일치에 의한 네트워크 장치의 오동작을 방지하고, 복잡한 롤백 시나리오를 미연에 방지하면서 네트워크 장치 동작의 신뢰성을 높일 수 있다.

Description

컨트롤러와 네트워크 장치 간에 번들 명령을 처리하는 방법{METHOD FOR PROCESSING BUNDLE MESSAGE BETWEEN CONTROLLER AND NETWORK EQUIPMENT}

본 발명은 소프트웨어 정의 네트워킹에 관한 것으로, 더욱 상세하게는 컨트롤러와 복수의 네트워크 장치 간에 번들 명령을 처리하는 방법에 관한 것이다.

최근 들어, 네트워크 장치의 트래픽 포워딩 기능과 제어 기능을 분리하여 통신 시스템을 효율적으로 운용하는 기술에 대한 표준화가 ONF(Open Networking Foundation), IETF(Internet Engineering Task Force), ETSI ISG NFV(Network Function Virtualization) 및 ITU-T 등을 중심으로 진행되고 있다.

SDN(Software Defined Networking)은 라우터나 스위치 등의 기본 네트워크 장비에 관계없이 사용자가 통제 권한을 가지며, 별도의 소프트웨어 컨트롤러가 트래픽 흐름을 제어하는 사용자 중심의 네트워크를 의미한다. 따라서, SDN에서는 사용자가 컨트롤러를 통해 네트워크를 바라보고 제어하기 때문에 컨트롤러의 역할이 중요하다.

SDN에서 사용자는 컨트롤러를 통해 네트워크 장치가 수행해야 할 액션(Action)을 생성하여 제어 메시지에 담아서 네트워크 장치로 전달하며, 네트워크 장치는 단순히 컨트롤러로부터 전달받은 액션(Action)을 수행하는 역할을 한다.

컨트롤러가 네트워크 장치에게 보낸 제어 메시지 안의 액션(Action)은 각각의 플로우 테이블(Flow table)의 엔트리(entry) 안에 저장되어 네트워크 장치가 실제 패킷을 처리하는 동작을 제어한다.

일반적으로 네트워크 컨트롤러(network controller)(이하, 컨트롤러)는 스위치(switch) 및 라우터(router) 등과 같은 네트워크 장치의 동작을 명세하고 설정값을 제어하는 등의 역할을 수행한다.

예를 들어, SDN에서 컨트롤러는 네트워크 장치의 플로우 테이블(flow table), 큐(queue) 등의 설정을 조정함으로써 SDN네트워크의 데이터 영역(data plane)의 동작을 제어할 수 있다. 이처럼 소수의 컨트롤러가 네트워크에 산재해 있는 다수의 네트워크 장치들을 중앙 집중적으로 제어하면 전체 네트워크에 대한 관리가 용이해지고 유지 비용이 감소하는 장점이 있다.

한편, 컨트롤러가 네트워크 장치를 정확하게 제어하기 위해서는 컨트롤러는 자신의 상태 정보와 네트워크 장치의 상태 정보를 동기화시킬 필요가 있다. 만약 컨트롤러와 네트워크 장치 간에 정보 동기화없이 불일치된 정보에 따라 제어가 발생하면 네트워크의 심각한 오동작을 초래할 수 있으며 이에 따라 복잡한 롤백(rollback) 시나리오가 수반될 수 있다. 또한, 롤백 시나리오는 실행 또는 처리된 명령의 개수가 많아질수록 더 심각해지는 문제점이 있다.

컨트롤러가 네트워크 장치에게 여러 제어 메시지들을 그룹으로 묶어서 동시에 전송하고 또 동시에 모두 실행시키고자 할 때 번들 명령을 사용할 수 있다.

번들 명령이 포함하는 제어 메시지들은 네트워크 장치 안에서 모두 적용되거나 아니면 하나라도 에러가 발생한 경우에는 모두 적용되지 않아야 한다.

번들 명령을 사용하는 또 다른 목적은, 여러 네트워크 장치들에게 동시에 번들 명령을 내리고, 이러한 번들 명령들 간에 동기화를 시켜서 복수의 네트워크 장치들이 일관성 있게 번들 명령을 적용하도록 하는 것이다. 즉, 컨트롤러가 복수의 네트워크 장치들에 내려보낸 번들 명령들은 서로 독립적인 것이 아니라 상호 연관성을 갖고 실행되어야 하는 경우에 유용하게 활용될 수 있다.

예를 들어, 복수의 네트워크 장치들에서 번들 명령 실행 중 일부 네트워크 장치에서 제어 메시지를 실행하다가 에러가 발생하면, 다른 네트워크 장치들에게 내려 보낸 제어 메시지 중에 영향을 받는 메시지들은 삭제를 하여야 한다.

또한, 복수의 네트워크 장치들에 번들 명령 실행 중에 일부 네트워크 장치에 내려 보낸 번들 명령에 실패가 발생할 수 있는데, 이러한 경우 다른 네트워크 장치들에 내려 보낸 번들 명령도 취소시켜야 할 필요가 있다.

그러나, 현재 ONF OpenFlow 표준안은 컨트롤러와 복수의 네트워크 장치들 간에 번들 명령이 성공적으로 실행되었을 경우에 대해서는 정의하고 있으나, 일부 네트워크 장치들에서 번들 명령 실행 중 에러가 발생한 경우에는 다른 네트워크 장치들도 지금까지 진행된 모든 절차를 중지하고 복잡한 롤-백(Roll-Back) 과정을 거쳐 처음부터 번들 명령을 다시 시작하여야 하는 문제점이 있다.

대한민국 공개특허공보 제10-2004-0047469호 (2004.6.5.)

상기와 같은 문제점을 해결하기 위한 본 발명의 목적은, 컨트롤러가 네트워크 장치에게 번들 실행 명령을 보내기 전에 네트워크 장치의 번들 명령 등록 상태를 확인 및 동기화하는 방법을 제공하는데 있다.

상기와 같은 문제점을 해결하기 위한 본 발명의 다른 목적은, 복수의 네트워크 장치들 중 일부에서 ADD_MESSAGE 실행 중에 에러가 발생하였을 때 모든 네트워크 장치들의 번들 명령을 취소하고 처음부터 번들 명령을 다시 시작해야 하는 문제를 해결하기 위한 방법을 제공하는데 있다.

상기와 같은 문제점을 해결하기 위한 본 발명의 또 다른 목적은, 복수의 네트워크 장치들 중 일부에서 COMMIT 명령 실행 중에 에러가 발생하더라도 다른 네트워크 장치들을 쉽게 번들 명령 이전 상태로 Roll-Back 시켜서 복수의 네트워크 장치들 간에 동기화를 시켜줄 수 있는 방법을 제공하는데 있다.

상기 목적을 달성하기 위한 본 발명의 실시예에 따른 번들 명령을 처리하는 방법은, 소프트웨어 정의 네트워킹에서 번들 명령을 처리하는 방법에 있어서, 컨트롤러가 적어도 하나의 네트워크 장치에 등록된 번들 명령에 대한 상태 확인 요청을 하는 단계와; 적어도 하나의 네트워크 장치가 상태 확인 요청에 따라 등록된 번들 명령의 상태를 확인하여 컨트롤러로 등록된 번들 명령에 대한 상태 확인 응답을 하는 단계와; 컨트롤러가 상태 확인 응답에 기반하여 등록된 번들 명령의 동일 여부를 판단하여 등록된 번들 명령을 처리하는 단계를 포함한다.

여기에서, 상기 등록된 번들 명령에 대한 상태 확인 요청을 하는 단계는, 등록된 번들 명령을 구분하기 위해 bundle-id를 활용할 수 있다.

여기에서, 상기 등록된 번들 명령에 대한 상태 확인 응답을 하는 단계는, bundle-id에 해당하는 등록된 번들 명령의 상태를 확인할 수 있다.

여기에서, 상기 등록된 번들 명령을 처리하는 단계는, 컨트롤러에 저장된 번들 명령과 등록된 번들 명령이 동일한지 판단하는 단계와; 컨트롤러에 저장된 번들 명령과 등록된 번들 명령이 상이한 것으로 판단됨에 따라 컨트롤러에 저장된 번들 명령을 기준으로 등록된 번들 명령에 대한 삭제, 추가 및 수정 중 적어도 하나의 요청을 하는 단계를 포함할 수 있다.

여기에서, 상기 컨트롤러에 저장된 번들 명령과 등록된 번들 명령이 동일한지 판단하는 단계는, bundle-id에 해당하는 등록된 번들 명령에 대해 트랜잭션 구분자 및 실행 등록 순서 배열이 컨트롤러에 저장된 번들 명령과 동일한지 판단할 수 있다.

여기에서, 상기 번들 명령을 처리하는 방법은, 상기 적어도 하나의 네트워크 장치가 상기 등록된 번들 명령에 대한 삭제, 추가 및 수정 중 적어도 하나의 요청에 따라 상기 등록된 번들 명령이 상기 컨트롤러에 저장된 번들 명령과 동일하게 되도록 상기 등록된 번들 명령을 동기화하는 단계를 더 포함할 수 있다.

상기 다른 목적을 달성하기 위한 본 발명의 실시예에 따른 번들 명령을 처리하는 방법은, 소프트웨어 정의 네트워킹에서 번들 명령을 처리하는 방법에 있어서, 컨트롤러가 적어도 하나의 네트워크 장치에 번들 명령 실행을 위한 실행 요청(COMMIT_REQUEST) 메시지를 전송하는 단계와; 적어도 하나의 네트워크 장치가 실행 요청 메시지에 따른 절차를 실행하고 실행 완료에 대한 응답으로 실행 응답(COMMIT_REPLY) 메시지를 컨트롤러로 전송하는 단계와; 컨트롤러는 실행 응답 메시지에 대한 확인으로 완료 번들(COMPLETE_BUNDLE) 메시지를 적어도 하나의 네트워크 장치에 전송하는 단계를 포함한다.

여기에서, 상기 번들 명령을 처리하는 방법은, 적어도 하나의 네트워크 장치가 완료 번들 메시지를 수신하여 번들 명령이 정상적으로 실행되었음을 확인하고, 번들 명령에 대한 정보를 삭제함과 동시에 완료 응답(COMPLETE_REPLY) 메시지를 상기 컨트롤러로 전송하는 단계를 더 포함할 수 있다.

상기 다른 목적을 달성하기 위한 본 발명의 실시예에 따른 번들 명령을 처리하는 방법은, 소프트웨어 정의 네트워킹에서 번들 명령을 처리하는 방법에 있어서, 컨트롤러가 적어도 하나의 네트워크 장치에 번들 명령 실행을 위한 실행 요청(COMMIT_REQUEST) 메시지를 전송하는 단계와; 적어도 하나의 네트워크 장치 각각이 실행 요청 메시지에 따른 절차를 실행하고, 실행 완료에 대한 응답으로 실행 응답(COMMIT_REPLY) 메시지 또는 실행 실패에 대한 응답으로 에러 응답(ERROR_REPLY) 메시지를 컨트롤러로 전송하는 단계와; 적어도 하나의 네트워크 장치 중 일부가 에러 응답 메시지를 전송함에 따라, 컨트롤러가 실행 응답 메시지를 전송한 네트워크 장치의 상태를 유지할 것인지 결정하는 단계를 포함한다.

여기에서, 상기 번들 명령을 처리하는 방법은, 컨트롤러가 실행 응답 메시지를 전송한 네트워크 장치의 상태를 번들 명령 실행 이전으로 되돌리는 것으로 결정한 경우, 컨트롤러가 실행 응답 메시지를 전송한 네트워크 장치에 복구 요청(RESTORE_REQUEST) 메시지를 전송하는 단계를 더 포함할 수 있다.

여기에서, 상기 번들 명령을 처리하는 방법은, 복구 요청(RESTORE_REQUEST) 메시지를 수신한 네트워크 장비가 번들 명령 실행 이전의 상태로 되돌아가고 컨트롤러로 복구 응답(RESTORE_REPLY) 메시지를 전송하는 단계를 더 포함할 수 있다.

여기에서, 상기 번들 명령을 처리하는 방법은, 컨트롤러가 실행 응답 메시지를 전송한 네트워크 장치의 상태를 유지하는 것으로 결정한 경우, 컨트롤러가 실행 응답 메시지에 대한 확인으로 완료 번들(COMPLETE_BUNDLE) 메시지를 실행 응답 메시지를 전송한 네트워크 장치로 전송하는 단계를 더 포함할 수 있다.

여기에서, 상기 번들 명령을 처리하는 방법은, 실행 응답 메시지를 전송한 네트워크 장치가 완료 번들 메시지를 수신하여 번들 명령이 정상적으로 실행되었음을 확인하고, 번들 명령에 대한 정보를 삭제함과 동시에 완료 응답(COMPLETE_REPLY) 메시지를 컨트롤러로 전송하는 단계를 더 포함할 수 있다.

상기 다른 목적을 달성하기 위한 본 발명의 실시예에 따른 번들 명령을 처리하는 방법은, 소프트웨어 정의 네트워킹에서 번들 명령을 처리하는 방법에 있어서, 컨트롤러가 적어도 하나의 네트워크 장치의 번들 명령에 추가될 제어 메시지를 포함하는 추가 메시지(ADD_MESSAGE)를 적어도 하나의 네트워크 장치로 전송하는 단계와; 적어도 하나의 네트워크 장치 중에서 일부가 추가 메시지에 대한 실행 과정에서 에러가 발생하여 에러 메시지(ERROR_MESSAGE)를 컨트롤러로 전송함에 따라, 컨트롤러가 추가 메시지를 실행 완료한 네트워크 장치의 상태를 유지할 것인지 결정하는 단계를 포함한다.

여기에서, 상기 번들 명령을 처리하는 방법은, 컨트롤러가 추가 메시지를 실행 완료한 네트워크 장치의 상태를 추가 메시지 실행 이전으로 되돌리는 것으로 결정한 경우, 컨트롤러가 추가 메시지를 실행 완료한 네트워크 장치에 삭제 메시지(DELETE_MESSAGE)를 전송하는 단계를 더 포함할 수 있다.

여기에서, 상기 번들 명령을 처리하는 방법은, 삭제 메시지(DELETE_MESSAGE)를 수신한 네트워크 장비가 추가 메시지 실행 이전으로 되돌아가는 단계를 더 포함할 수 있다.

여기에서, 상기 번들 명령을 처리하는 방법은, 컨트롤러가 추가 메시지를 실행 완료한 네트워크 장치의 상태를 유지하는 것으로 결정한 경우, 컨트롤러가 추가적인 추가 메시지의 수신을 거부하도록 하는 클로즈 요청(CLOSE_REQUEST) 메시지를 적어도 하나의 네트워크 장치로 전송하는 단계를 더 포함할 수 있다.

여기에서, 상기 번들 명령을 처리하는 방법은, 적어도 하나의 네트워크 장치가 클로즈 요청 메시지에 대한 응답으로 클로즈 응답(CLOSE REPLY) 메시지를 컨트롤러로 전송하는 단계를 더 포함할 수 있다.

상기와 같은 본 발명의 실시예에 따르면, 컨트롤러가 네트워크 장치의 번들 명령을 실행하기 전에 번들 명령 상태를 확인하고 동기화시킴으로써 컨트롤러와 네트워크 장치간 번들 명령 불일치에 의한 네트워크 장치의 오동작을 방지하고, 복잡한 롤백 시나리오를 미연에 방지하면서 네트워크 장치 동작의 신뢰성을 높일 수 있다.

또한, 컨트롤러가 복수의 네트워크 장치들에게 번들 명령을 내려 보낼 때 네트워크 장치들 중 일부에서 ADD_MESSAGE 실행 중에 에러가 발생하더라도 영향을 받는 일부 ADD_MESSAGE만 선별적으로 삭제하고 다음 번들 명령 절차를 진행할 수 있도록 함으로써, 번들 명령을 짧은 시간에 효율적으로 실행할 수 있다.

또한, 컨트롤러가 복수의 네트워크 장치들에게 번들 명령을 내려 보낼 때 네트워크 장치들 중 일부에서 COMMIT 명령 실행 중에 에러가 발생하더라도 다른 네트워크 장치들을 쉽게 번들 명령 이전 상태로 롤-백(Roll-Back)시킴으로써 복수의 네트워크 장치들간에 번들 명령을 동기화하고 이를 통하여SDN 네트워크의 신뢰성과 운용의 편리성을 높일 수 있다.

도 1은 본 발명의 실시예에 따른 번들 명령의 실행을 설명하기 위한 개념도이다.
도 2는 본 발명의 실시예에 따른 번들 명령을 처리하는 방법을 수행하는 시스템을 설명하기 위한 블록도이다.
도 3은 본 발명의 실시예에 따른 번들 명령을 처리하는 방법을 설명하기 위한 순서도이다.
도 4는 본 발명의 실시예에 따른 번들 명령을 처리하는 방법에서 사용되는 메시지 속성을 설명하기 위한 도면이다.
도 5는 본 발명의 실시예에 따라 컨트롤러가 복수의 네트워크 장치로 번들 명령을 전송하여 실행시키는 과정을 설명하기 위한 개념도이다.
도 6은 컨트롤러가 복수의 네트워크 장치에 대해 번들 명령을 성공적으로 실행시킨 경우의 일반적인 처리 절차를 설명하기 위한 순서도이다.
도 7은 복수의 네트워크 장치들 중 하나의 장치에서 ADD_MESSAGE 실행 중 에러가 발생한 경우의 일반적인 처리 절차를 설명하기 위한 순서도이다.
도 8은 복수의 네트워크 장치들 중 하나의 장치에서 COMMIT_REQUEST 실행 중 에러가 발생한 경우의 일반적인 처리 절차를 설명하기 위한 순서도이다.
도 9은 본 발명의 실시예에 따라 컨트롤러와 네트워크 장치 간에 번들 명령의 실행이 모두 성공적으로 완료된 경우의 처리 절차를 설명하기 위한 순서도이다.
도 10은 본 발명의 일 실시예에 따라 ADD_MESSAGE 실행 중 에러가 발생한 경우의 처리 절차를 설명하기 위한 순서도이다.
도 11은 본 발명의 다른 실시예에 따라 ADD_MESSAGE 실행 중 에러가 발생한 경우의 처리 절차를 설명하기 위한 순서도이다.
도 12는 본 발명의 일 실시예에 따라 COMMIT_REQUEST 실행 중 에러가 발생한 경우의 처리 절차를 설명하기 위한 순서도이다.
도 13은 본 발명의 다른 실시예에 따라 COMMIT_REQUEST 실행 중 에러가 발생한 경우의 처리 절차를 설명하기 위한 순서도이다.

본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세한 설명에 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다. 각 도면을 설명하면서 유사한 참조부호를 유사한 구성요소에 대해 사용하였다.

제1, 제2, A, B 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. 및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.

어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.

본 출원에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가지는 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.

이하, 본 발명에서 언급되는 컨트롤러는 통합 SDN 컨트롤러(Unified SDN controller)로, 트래픽의 흐름을 제어하기 위해 관련 구성 요소(예를 들면, 스위치, 라우터 등)를 제어하는 기능 요소(entity)를 의미할 수 있다.

또한, 컨트롤러는 물리적인 구현 형태나 구현 위치 등에 의해 한정되지 않는다. 예를 들어, 컨트롤러는 ONF(OpenFlow), IETF(Internet Engineering Task Force), ETSI(European Telecommunication Standards Institute) 및/또는 ITU-T(International Telecommunication Union Telecommunication) 등에서 정의하고 있는 컨트롤러 기능 요소(entity)를 의미할 수 있다.

본 발명에서 언급되는 네트워크 장치는 '스위치(switch)' 또는 '라우터(router)'와 같이 트래픽(또는 패킷)을 실질적으로 포워딩하거나 스위칭 또는 라우팅하는 기능 요소를 의미할 수 있다. 따라서, 본 발명에서 네트워크 장치는 스위치 또는 라우터로 명명될 수 있다.

예를 들어, 네트워크 장치는 ONF, IETF, ETSI 및/또는 ITU-T 등에서 정의하고 있는 스위치, 라우터, 스위치 요소(Switching Element), 라우터 요소(Routing Element), 포워딩 요소(Forwarding Element) 등을 의미할 수 있다.

이하, 본 발명의 실시예들에서는 컨트롤러와 네트워크 장치 간에 번들 명령 실행을 동기화시키기 위한 동작 과정에서 ONF에서 정의된 파라미터 및/또는 메시지 형태(예를 들면, OPEN, CLOSE, COMMIT Request/Reply)를 이용하는 것으로 예를 들어 도시하였으나, 본 발명의 기술적 사상이 ONF에 정의된 내용으로만 한정되는 것은 아니며 컨트롤러와 복수의 네트워크 장치간 번들 명령 동기화 과정에서 컨트롤러와 네트워크 장치를 구분할 수 있는 다양한 파라미터를 이용할 수 있고, 상기 번들 명령 동기화를 위해 사용되는 메시지들도 후술하는 특정 메시지에 한정되지 않는다.

이하, 본 발명에 따른 바람직한 실시예를 첨부된 도면을 참조하여 상세하게 설명한다.

도 1은 본 발명의 실시예에 따른 번들 명령의 실행을 설명하기 위한 개념도이다.

네트워크 장치 내에서 다수의 명령이 동시에 또는 순차적으로 실행되도록 하기 위해 컨트롤러는 네트워크 장치에게 다수의 명령을 번들(bundle)로 등록하게 하고 네트워크 장치가 번들 명령을 실행시키도록 하는 것이 가능하다.

도 1을 참조하여 번들을 실행하는 과정을 개략적으로 설명한다.

먼저, 컨트롤러가 네트워크 장치에게 번들 생성을 요청하면 네트워크 장치는 내부 메모리에 번들을 생성하고 번들 생성 응답을 컨트롤러에게 보낼 수 있다. 여기서, 번들을 구분하기 위한 번들의 구분자는 bundle-id를 사용할 수 있다.

다음으로, 컨트롤러는 생성한 번들(구분자 bundle-id)에 대해 1개 또는 그 이상의 번들 명령을 추가할 수 있다. 도 1은 3개의 명령을 추가하는 예시를 도시하였으며, 이는 각각의 번들 명령은 서로 다른 트랜잭션 구분자(xid)로 구분될 수 있다.

번들 명령을 추가하는 과정에 의해 컨트롤러와 네트워크 장치는 3개의 번들 명령(MSG1, MSG2, MSG3)을 번들에 매핑할 수 있다.

마직막으로, 컨트롤러는 번들을 실행하도록 네트워크 장치에 요청할 수 있다. 네트워크 장치는 요청받은 번들을 실행한 뒤, 그 결과를 컨트롤러에게 응답할 수 있다. 따라서 컨트롤러는 번들 명령 생성 및 실행 방법을 통해 네트워크 장치가 동시에 또는 순차적으로 명령을 처리하도록 할 수 있다.

그러나, 도 1에서 설명한 번들 명령 생성 및 실행 방법을 수행함에 있어서, 컨트롤러와 네트워크 장치가 번들에 대해 서로 다른 번들 명령 정보를 갖고 있다면 네트워크 장치는 컨트롤러가 예상하지 못한 형태로 오동작할 수 있다.

예를 들어, 컨트롤러는 bundle-id=100인 번들에 대해 번들 명령을 MSG1(xid=11), MSG2(xid=12), MSG3(xid=13)을 매핑하고 있으나, 네트워크 장치는 bundle-id=100인 번들에 대해 번들 명령을 MSG1(xid=11), MSG4(xid=14), MSG5(xid=15)을 매핑할 수 있다. 이러한 경우, 번들이 실행되었을 때 MSG1(xid=11)은 정상적으로 실행되지만 MSG2(xid=12)와 MSG3(xid=13)은 실행되지 않고 MSG4(xid=14)와 MSG5(xid=15)는 불필요하게 실행될 수 있다.

따라서 컨트롤러와 네트워크 장치간의 정보 불일치로 인한 네트워크 장치의 오동작이 발생하게 되며, 네트워크 장치의 오동작으로 인해 전체 네트워크의 기능이 컨트롤러가 예상하지 않는 방향으로 동작하게 된다.

따라서, 번들 명령을 실행하기 전에 컨트롤러가 네트워크 장치의 번들 명령 등록 상태를 조회하여 동기화시키는 방법을 제공하지 않는다면, 네트워크 장치의 번들 정보가 컨트롤러의 번들 정보와 불일치함에 따른 네트워크 장치의 복잡한 롤백 실행 등의 문제점이 있을 수 있다.

도 2는 본 발명의 실시예에 따른 번들 명령을 처리하는 방법을 수행하는 시스템을 설명하기 위한 블록도이다.

도 2를 참조하여, 본 발명의 실시예에 따른 컨트롤러(100)와 네트워크 장치(200)의 구성을 설명한다.

먼저, 컨트롤러(100)는 네트워크 장치 제어부(110), 번들 명령 처리부(120), 번들 명령 저장부(130), 플로우 테이블 관리부(140) 및 네트워크 장치 연동부(150)를 포함할 수 있다.

네트워크 장치 제어부(110)는 제어 명령(Flow table entry 추가/수정/삭제)을 생성하여 네트워크 장치(200)를 제어할 수 있다.

번들 명령 처리부(120)는 번들 명령을 처리할 수 있다. 즉, 번들 명령 처리부(120)는 네트워크 장치(200)의 번들 명령 상태를 조회하여 네트워크 장치(200)의 번들 명령을 동기화시킬 수 있다.

단일 메시지로 이루어진 제어 명령은 네트워크 장치 제어부(110)에서 처리될 수 있고, 복수의 메시지로 이루어진 번들 명령은 번들 명령 처리부(120)를 통해서 처리될 수 있다.

번들 명령 저장부(130)는 번들 별로 네트워크 장치(200)에 등록한 번들 명령을 컨트롤러(100) 자체에 등록하고 저장하는 기능을 수행할 수 있다.

플로우 테이블 관리부(140)는 각각의 네트워크 장치(200)에 대한 플로우 테이블(Flow table)을 관리할 수 있다.

네트워크 장치 연동부(150)는 네트워크 장치(200)와 통신하기 위한 프로토콜을 관리할 수 있다.

네트워크 장치(200)는 네트워크 장치 자체적으로 제어를 수행하는 네트워크 장치 제어부(210), 컨트롤러(100)로부터 전달받은 번들 명령을 실행하는 번들 명령 처리부(220), 네트워크 장치(200) 자체적으로 번들 명령을 저장하는 기능을 수행하는 번들 명령 저장부(230), 네트워크 장치(200)에서 플로우 테이블을 관리하는 플로우 테이블 관리부(240) 및 컨트롤러(100)와 통신하기 위한 컨트롤러(100) 연동부(250)를 포함하여 구성될 수 있다.

또한, 네트워크 장치(200)에서도 단일 메시지로 이루어진 제어 명령은 네트워크 장치 제어부(210)에서 처리될 수 있고, 복수의 메시지로 이루어진 번들 명령은 번들 명령 처리부(220)를 통해서 처리될 수 있다.

도 3은 본 발명의 실시예에 따른 번들 명령을 처리하는 방법을 설명하기 위한 순서도이고, 도 4는 본 발명의 실시예에 따른 번들 명령을 처리하는 방법에서 사용되는 메시지 속성을 설명하기 위한 도면이다.

도 3은 본 발명의 실시예에 따른 컨트롤러(100)와 네트워크 장치(200)간의 메시지 흐름도를 도시한 것으로, 컨트롤러(100)와 네트워크 장치(200)간의 번들 명령 상태 확인 및 동기화 절차를 나타낸다.

도 3 및 도 4를 참조하여 컨트롤러(100)가 네트워크 장치(200)에 등록한 번들 명령의 상태를 조회하여 그것이 컨트롤러(100) 내부의 번들 명령 저장부(130)에 저장된 것과 다를 경우 동기화를 수행하는 절차를 설명한다.

컨트롤러(100)는 네트워크 장치(200)에 등록된 번들 명령에 대한 상태 확인 요청을 할 수 있고(S310), 네트워크 장치(200)는 상태 확인 요청에 따라 네트워크 장치(200)에 등록된 번들 명령의 상태를 확인하여 컨트롤러(100)로 네트워크 장치(200)에 등록된 번들 명령에 대한 상태 확인 응답을 수행할 수 있다(S320). 예를 들어, 네트워크 장치(200)에 등록된 번들 명령을 구분하기 위해 bundle-id를 활용할 수 있으며, bundle-id에 해당하는 네트워크 장치(200)에 등록된 번들 명령의 상태를 확인할 수 있다.

컨트롤러(100)는 상태 확인 응답에 기반하여 네트워크 장치(200)에 등록된 번들 명령의 동일성 여부를 판단할 수 있다(S330). 즉, 컨트롤러(100)에 저장되어 있는 번들 명령과 네트워크 장치(200)에 등록된 번들 명령이 동일한지 판단할 수 있다. 예를 들어, bundle-id에 해당하는 네트워크 장치(200)에 등록된 번들 명령에 대해 트랜잭션 구분자 및 실행 등록 순서 배열이 컨트롤러(100)에 저장된 번들 명령과 동일한지 판단할 수 있다.

컨트롤러(100)는 컨트롤러(100)에 저장되어 있는 번들 명령과 네트워크 장치(200)에 등록된 번들 명령이 상이한 것으로 판단됨에 따라 컨트롤러(100)에 저장된 번들 명령을 기준으로 네트워크 장치(200)에 등록된 번들 명령에 대한 삭제, 추가 및 수정 중 적어도 하나를 요청하고 이를 수행한 결과를 응답 받을 수 있다(S340, S350, S360).

도 4를 참조하여 컨트롤러와 네트워크 장치간의 번들 명령 상태 확인 및 동기화 절차를 보다 상세히 설명하면 다음과 같다.

먼저, 번들 상태 확인 요청에 대한 절차를 설명하면 다음과 같다.

컨트롤러(100)의 번들 명령 처리부(120)는 네트워크 장치 연동부(150)를 통해 네트워크 장치(200)에게 특정 번들 명령에 대한 상태 조회를 요청할 수 있다. 이때, 번들 상태 확인 요청을 위한 메시지의 Type은 VERIFY request가 되며, 번들의 구분은 bundle-id 속성을 이용하여 구분할 수 있다.

다음으로, 번들 상태 확인 응답에 대한 절차를 설명하면 다음과 같다.

네트워크 장치(200)는 컨트롤러(100)로부터 받은 번들 상태 확인 요청에 대해 bundle-id에 해당되는 번들 명령의 상태를 확인하여 컨트롤러(100)에게 응답할 수 있다. 이때, 번들 상태 확인 응답을 위한 메시지의 Type은 VERIFY reply가 되며, 번들의 구분은 bundle-id 속성을 이용하여 구분할 수 있다.

또한, 하나의 번들에 다수의 번들 명령이 등록되어 있을 경우, Message 속성을 이용하여 다수의 번들 명령의 배열 형태를 표시할 수 있고, 각 명령 별 실행 등록 순서는 Order 속성을 이용하여 표시할 수 있다.

예를 들어, MSG1이 1번, MSG2가 3번, MSG3이 2번 실행 등록 순서인 경우, Message 속성은 (MSG1, MSG2, MSG3)의 배열 형태로 값이 전달되고 Order 속성은 (1, 3, 2)의 배열 형태로 값이 전달될 수 있다. 여기서, Message 속성, transaction id 등의 트랜잭션 구분자를 포함함으로써 고유한 명령 등록 상태를 구분할 수 있다.

다음으로, 번들 명령의 동일성 여부를 판단하는 절차를 설명하면 다음과 같다.

컨트롤러(100)는 자신의 번들 명령 저장부(130)에 저장된 bundle-id에 해당되는 번들 명령 등록 상태와 네트워크 장치(200)로부터 전달받은 bundle-id에 해당되는 번들 명령 등록 상태를 비교하여 서로 동일한지 여부를 판단할 수 있다.

이때, 판단 기준은 번들 명령의 트랜잭션 구분자와 실행 등록 순서 배열이 서로 동일한지 여부일 수 있다.

컨트롤러(100)에 저장되어 있는 번들 명령과 네트워크 장치(200)에 등록된 번들 명령이 서로 동일하면, 컨트롤러(100)는 동기화 절차를 더 이상 수행하지 않는다.

그러나, 컨트롤러(100)에 저장되어 있는 번들 명령과 네트워크 장치(200)에 등록된 번들 명령이 상이하면, 컨트롤러(100)는 동기화 절차를 수행할 수 있다.

마지막으로, 번들 명령에 대한 동기화 절차를 설명하면 다음과 같다.

컨트롤러(100)의 번들 명령 처리부(120)는 번들 명령 저장부(130)에 저장된 bundle-id의 번들 명령을 확인하여 네트워크 장치(200)로부터 전달받은 Message 속성을 비교한 뒤, 다음과 같이 컨트롤러(100)의 번들 명령 저장부(130)에 저장된 번들 명령을 기준으로 3가지로 구분된 동기화를 수행할 수 있다.

첫 번째, 컨트롤러(100)의 번들 명령 처리부(120)는 네트워크 장치(200)에 등록된 번들 명령에는 존재하지만 컨트롤러(100)의 번들 명령 저장부(120)에는 존재하지 않는 번들 명령에 대해서는 네트워크 장치(200)에 번들 명령 삭제 메시지를 보내어 해당 번들 명령을 삭제하도록 요청할 수 있다.

두 번째로, 컨트롤러(100)의 번들 명령 처리부(120)는 네트워크 장치(200)에 등록된 번들 명령에는 존재하지 않지만 컨트롤러(100)의 번들 명령 저장부(130)에만 존재하는 번들 명령에 대해서는 네트워크 장치(200)에 번들 명령 추가 메시지를 보내어 네트워크 장치(200)에 해당 번들 명령을 추가하도록 요청할 수 있다. 이 때, 번들 명령의 Order 속성도 함께 표시할 수 있다.

세 번째로, 컨트롤러(100)의 번들 명령 처리부(120)는 네트워크 장치(200)에 등록된 번들 명령에도 존재하고 컨트롤러(100)의 번들 명령 저장부(130)에도 존재하는 번들 명령에 대해서는 Order 속성을 비교하여 서로 다르면 번들 명령 수정 메시지를 보내어 해당 번들 명령에 대한 번들 실행 등록 순서를 재조정할 수 있다.

도 5는 본 발명의 실시예에 따라 컨트롤러(100)가 복수의 네트워크 장치로 번들 명령을 전송하여 실행시키는 과정을 설명하기 위한 개념도이다.

도 5를 참조하면, 컨트롤러(100)는 3개의 네트워크 장치로 동시에 번들 명령을 전달하여 제1 네트워크 장치(200-1) - 제2 네트워크 장치(200-2) - 제3 네트워크 장치(200-3)와 같은 경로로 2개의 MPLS-LSP(MultiProtocol Label Switching - Label Switching Path)를 동시에 구성할 수 있다.

컨트롤러(100)는 각각의 네트워크 장치(200-1, 200-2, 200-3)에 대해 LSP1과 LSP2를 구성해야 하기 때문에, 각각의 네트워크 장치(200-1, 200-2, 200-3)마다 2개의 제어 메시지를 하나의 번들에 담아서 실행시킬 수 있다.

즉, LSP1을 구성하기 위하여 제1 네트워크 장치(200-1), 제2 네트워크 장치(200-2) 및 제3 네트워크 장치(200-3) 모두에 LSP1을 위한 제어 메시지를 적용할 수 있다. 또한, LSP2를 구성하기 위하여 제1 네트워크 장치(200-1), 제2 네트워크 장치(200-2) 및 제3 네트워크 장치(200-3) 모두에 LSP2를 위한 제어 메시지를 적용할 수 있다.

도 6은 컨트롤러가 복수의 네트워크 장치에 대해 번들 명령을 성공적으로 실행시킨 경우의 일반적인 처리 절차를 설명하기 위한 순서도이다.

도 6을 참조하면, 오픈 요청(OPEN_REQUEST) 메시지, 오픈 응답(OPEN_REPLY) 메시지, 추가 메시지(ADD_MESSAGE), 클로즈 요청(CLOSE_REQUEST) 메시지, 클로즈 응답(CLOSE_REPLY) 메시지, 실행 요청(COMMIT_REQUEST) 메시지 및 실행 응답(COMMIT_REPLY) 메시지를 이용하여 번들 명령을 실행할 수 있다.

S610는 번들 명령 실행을 시작하는 단계로, S610 단계를 설명하면 다음과 같다.

컨트롤러(100)는 번들 명령을 실행하기 위해 OPEN_REQUEST 메시지를 각각의 네트워크 장치(200-1, 200-2, 200-3)로 전송하고 각각의 네트워크 장치(200-1, 200-2, 200-3)는 컨트롤러(100)로 OPEN_REPLY 메시지를 전송해서 번들이 성공적으로 오픈(OPEN)되었음을 알려줄 수 있다.

OPEN_REQUEST 메시지는 bundle_id 라는 파라미터를 포함하여 전송될 수 있다. 여기서, bundle_id는 컨트롤러(100)-네트워크 장치 연결 안에서는 고유한 값을 사용하여야 하고, 번들 명령 실행이 끝난 후에는 다음 번들 명령에서 재사용될 수 있다.

S620는 번들 명령을 추가하는 단계로, S620 단계를 설명하면 다음과 같다.

컨트롤러(100)는 각각의 네트워크 장치(200-1, 200-2, 200-3)에 보낼 제어 메시지를 ADD_MESSAGE에 담아서 각각의 네트워크 장치(200-1, 200-2, 200-3)로 전송할 수 있다.

제어 메시지가 n개 일 경우, ADD_MESSAGE 마다 하나의 제어 메시지를 담아서 n개의 ADD_MESSAGE를 네트워크 장치로 전송할 수 있다. 각각의 네트워크 장치(200-1, 200-2, 200-3)는 ADD_MESSAGE를 받아서 바로 실행시키지 않고 제어 메시지들을 임시 저장소에 저장할 수 있다.

여기서, ADD_MESSAGE는 xid라는 파라미터를 포함할 수 있으며, xid는 컨트롤러(100)-네트워크 장치 연결 안에서는 고유한 값을 사용하여야 하고, 제어 메시지를 구분하기 위해 사용될 수 있다.

S630는 번들을 클로즈하는 단계로, S630 단계를 설명하면 다음과 같다.

ADD_MESSAGE를 모두 전송한 후에 컨트롤러(100)는 CLOSE_REQUEST 메시지를 각각의 네트워크 장치(200-1, 200-2, 200-3)로 보내서 해당 번들을 클로즈(CLOSE)시킬 수 있다.

해당 번들을 클로즈한 후에, 각각의 네트워크 장치(200-1, 200-2, 200-3)는 컨트롤러(100)로 CLOSE_REPLY 메시지를 전송할 수 있다. 번들이 클로즈된 후에는 추가적인 ADD_MESSAGE를 받을 수 없으며, 만일 ADD_MESSAGE가 들어오면 각각의 네트워크 장치(200-1, 200-2, 200-3)는 컨트롤러(100)로 에러 메시지를 전송할 수 있다. 각각의 네트워크 장치(200-1, 200-2, 200-3)는 번들을 클로즈한 후에도 제어 메시지들을 실행시키지 않고 임시로 저장할 수 있다.

S640은 번들을 실행하는 단계로, S640 단계를 설명하면 다음과 같다.

번들을 클로즈한 후에 컨트롤러(100)는 COMMIT_REQUEST 메시지를 각각의 네트워크 장치(200-1, 200-2, 200-3)로 보내서 번들 명령을 실행할 수 있다. 각각의 네트워크 장치(200-1, 200-2, 200-3)는 COMMIT_REQUEST 메시지를 받으면 임시로 저장하고 있던 제어 메시지들을 네트워크 장치(200-1, 200-2, 200-3)에 적용하고 성공적으로 적용하고 나면 COMMIT_REPLY 메시지를 컨트롤러(100)로 전송할 수 있다.

도 7은 복수의 네트워크 장치들 중 하나의 장치에서 ADD_MESSAGE 실행 중 에러가 발생한 경우의 일반적인 처리 절차를 설명하기 위한 순서도이다.

S710는 번들 명령 실행을 시작하는 단계로, S710 단계를 설명하면 다음과 같다.

S720는 번들 명령을 추가하는 단계로, S720 단계를 설명하면 다음과 같다.

이때, 제3 네트워크 장치(200-3)에서 ADD_MESSAGE(xid=c2)를 받고 메시지 검증 과정에서 에러가 검출되는 경우, ERROR_MESSAGE 를 컨트롤러(100)로 전송할 수 있다. 네트워크 장치(200)가 ADD_MESSAGE를 받고 에러를 발생하는 경우는 다음과 같은 경우들이 있을 수 있다.

- 번들이 이미 CLOSE 상태인 경우

- Flags 가 다른 번들 메시지와 다른 경우

- 번들에 수용할 수 없는 메시지인 경우

- 번들에 포함된 다른 메시지와 호환이 안되는 경우

- 번들이 full 상태인 경우

- Length field가 valid 하지 않은 경우

- 번들 안에 중복된 xid를 갖는 메시지가 있는 경우

S730은 번들 명령을 취소하는 단계로, S730 단계를 설명하면 다음과 같다.

ADD_MESSAGE(xid=c2)에서 발생한 에러로 인해 제1 네트워크 장치(200-1) 및 제2 네트워크 장치(200-2)로 전송한 ADD_MESSAGE(xid=a2)와 ADD_MESSAGE(xid=b2)의 실행이 불필요하다고 판단되는 경우에, 컨트롤러(100)는 각각의 네트워크 장치(200-1, 200-2, 200-3)로 취소 요청(DISCARD_REQUEST) 메시지를 보내서 번들 명령 전체를 취소시킬 수 있다. 또한, 각각의 네트워크 장치(200-1, 200-2, 200-3)은 취소 요청(DISCARD_REQUEST) 메시지에 대한 응답으로 취소 응답(DISCARD_REPLY) 메시지를 컨트롤러(100)로 전달할 수 있다.

컨트롤러(100)는 각각의 네트워크 장치(200-1, 200-2, 200-3)로 취소 요청(DISCARD_REQUEST) 메시지를 보내서 번들 명령 전체를 취소시킨 후에 OPEN_REQUEST 메시지를 이용하여 다시 번들 명령을 시작할 수 있다(S740).

도 8은 복수의 네트워크 장치들 중 하나의 장치에서 COMMIT_REQUEST 실행 중 에러가 발생한 경우의 일반적인 처리 절차를 설명하기 위한 순서도이다.

S810는 번들 명령 실행을 시작하는 단계로, S810 단계를 설명하면 다음과 같다.

OPEN_REQUEST 메시지는 bundle_id 라는 파라미터를 포함하여 전송될 수 있다. 여기서, bundle_id는 컨트롤러(100)-네트워크 장치(200) 연결 안에서는 고유한 값을 사용하여야 하고, 번들 명령 실행이 끝난 후에는 다음 번들 명령에서 재사용될 수 있다.

S820는 번들 명령을 추가하는 단계로, S820 단계를 설명하면 다음과 같다.

S830는 번들을 클로즈하는 단계로, S830 단계를 설명하면 다음과 같다.

해당 번들을 클로즈한 후에, 각각의 네트워크 장치(200-1, 200-2, 200-3)는 컨트롤러(100)로 CLOSE_REPLY 메시지를 전송할 수 있다. 번들이 클로즈된 후에는 추가적인 ADD_MESSAGE를 받을 수 없으며, 만일 ADD_MESSAGE가 들어오면 각각의 네트워크 장치(200-1, 200-2, 200-3)는 컨트롤러(100)로 에러 메시지(ERROR_MESSAGE)를 전송할 수 있다. 각각의 네트워크 장치(200-1, 200-2, 200-3)는 번들을 클로즈한 후에도 제어 메시지들을 실행시키지 않고 임시로 저장할 수 있다.

S840은 번들을 실행하는 단계로, S840 단계를 설명하면 다음과 같다.

번들을 클로즈한 후에 컨트롤러(100)는 COMMIT_REQUEST 메시지를 각각의 네트워크 장치(200-1, 200-2, 200-3)로 보내서 번들 명령을 실행할 수 있다. 각각의 네트워크 장치(200-1, 200-2, 200-3)는 COMMIT_REQUEST 메시지를 받으면 임시로 저장하고 있던 제어 메시지들을 네트워크 장치(200-1, 200-2, 200-3)에 적용하고 성공적으로 적용하고 나면 COMMIT_REPLY 메시지를 컨트롤러(100)로 전송하고 실행된 번들 명령에 대한 정보를 삭제할 수 있다.

그러나, 제3 네트워크 장치(200-3)가 번들 명령 실행 중에 에러가 발생하면, 제3 네트워크 장치는 해당 번들 명령에 대한 롤-백(Roll-Back)을 수행한 후 컨트롤러(100)로 ERROR_REPLY 메시지를 전송하고 번들 명령에 대한 정보를 삭제할 수 있다.

제1 네트워크 장치 및 제2 네트워크 장치는 이미 번들 명령을 성공적으로 실행하고 컨트롤러(100)에게 COMMIT_REPLY 메시지를 전송한 상태이다. 이때, 제3 네트워크 장치의 번들 명령 실행 실패로 제1 네트워크 장치 및 제2 네트워크 장치의 번들 명령도 롤-백(Roll-Back)시켜야 하는 경우가 발생할 수 있다.

여기서, 네트워크 장치가 COMMIT_REQUEST 메시지 실행 중에 에러를 발생하는 경우는 다음과 같은 경우들이 있을 수 있다.

- Bundle_id에 맞는 번들이 없는 경우

- Flags가 다른 번들 메시지와 다른 경우

- 번들 메시지를 네트워크 장치에 적용하다가 에러가 발생한 경우

이러한 경우, 제1 네트워크 장치(200-1) 및 제2 네트워크 장치(200-2)는 이미 번들 명령을 성공적으로 실행하고 번들 명령에 대한 정보를 삭제한 상태이다. 따라서, 컨트롤러(100)는 제1 네트워크 장치(200-1) 및 제2 네트워크 장치(200-2)를 번들 명령 실행 이전의 상태로 만들어 주기 위해 제1 네트워크 장치(200-1)과 제2 네트워크 장치(200-2)에 새로운 번들 명령을 전달하여 실행할 수 있다.

이러한 경우, 컨트롤러(100)는 제1 네트워크 장치(200-1) 및 제2 네트워크 장치(200-2)에 대해 새로운 번들 명령을 만들어서 S810부터 S840까지 다시 실행하여야 하는 단점이 있다(S850).

도 9은 본 발명의 실시예에 따라 컨트롤러(100)와 네트워크 장치 간에 번들 명령의 실행이 모두 성공적으로 완료된 경우의 처리 절차를 설명하기 위한 순서도이다.

S910는 번들 명령 실행을 시작하는 단계로, S910 단계를 설명하면 다음과 같다.

S920는 번들 명령을 추가하는 단계로, S920 단계를 설명하면 다음과 같다.

여기서, ADD_MESSAGE는 xid라는 파라미터를 포함할 수 있으며, xid는 컨트롤러(100)-네트워크 (200) 연결 안에서는 고유한 값을 사용하여야 하고, 제어 메시지를 구분하기 위해 사용될 수 있다.

S930는 번들을 클로즈하는 단계로, S930 단계를 설명하면 다음과 같다.

S940은 번들을 실행하는 단계로, S940 단계를 설명하면 다음과 같다.

번들을 클로즈한 후에 컨트롤러(100)는 COMMIT_REQUEST 메시지를 각각의 네트워크 장치(200-1, 200-2, 200-3)로 보내서 번들 명령을 실행할 수 있다. 각각의 네트워크 장치(200-1, 200-2, 200-3)는 COMMIT_REQUEST 메시지를 받으면 임시로 저장하고 있던 제어 메시지들을 네트워크 장치(200-1, 200-2, 200-3)에 적용하고 성공적으로 적용하고 나면 COMMIT_REPLY 메시지를 컨트롤러(100)로 전송하고, 다른 네트워크 장치들이 번들 명령을 성공적으로 실행하였는지 확인될 때까지 번들 명령에 대한 정보를 삭제하지 않고 유지할 수 있다.

S950은 번들 명령의 성공적 실행을 확인하는 단계로, S950 단계를 설명하면 다음과 같다.

컨트롤러(100)는 번들 명령을 내린 모든 네트워크 장치(200-1, 200-2, 200-3)로부터 COMMIT_REPLY 메시지를 받으면 완료 번들(COMPLETE_BUNDLE) 메시지를 모든 네트워크 장치들에게 전송할 수 있다. 각각의 네트워크 장치(200-1, 200-2, 200-3)는 컨트롤러(100)로부터 COMPLETE_BUNDLE 메시지를 받으면 다른 네트워크 장치들도 번들 명령을 성공적으로 실행하였다고 판단할 수 있고, 이에 대한 응답으로 완료 응답(COMPLETE_REPLY) 메시지를 컨트롤러(100)로 전달한 후에 해당 번들 명령에 대한 정보를 네트워크 장치에서 삭제할 수 있다.

따라서, 컨트롤러(100)는 모든 네트워크 장치(200-1, 200-2, 200-3)로부터 COMPLETE_REPLY 메시지를 받은 후에 번들 명령 절차 종료할 수 있다.

상기 S910 내지 S950 단계를 통해, 컨트롤러(100)는 복수의 네트워크 장치(200-1, 200-2, 200-3)에게 번들 명령을 동시에 실행시킬 수 있으며, 모든 네트워크 장치(200-1, 200-2, 200-3)가 번들 명령을 성공적으로 실행한 후에 번들 명령 절차를 종료할 수 있다.

도 10은 본 발명의 일 실시예에 따라 ADD_MESSAGE 실행 중 에러가 발생한 경우의 처리 절차를 설명하기 위한 순서도이다.

S1010는 번들 명령 실행을 시작하는 단계로, S1010 단계를 설명하면 다음과 같다.

S1020는 번들 명령을 추가하는 단계로, S1020 단계를 설명하면 다음과 같다.

이때, 제3 네트워크 장치(200-3)에서 ADD_MESSAGE(xid=c2)를 받고 메시지 검증 과정에서 에러가 검출되는 경우, ERROR_MESSAGE 를 컨트롤러(100)로 전송할 수 있다.

S1030는 번들 명령 추가 과정에서 에러가 발생한 경우의 처리 단계로, S1030 단계를 설명하면 다음과 같다.

컨트롤러(100)는 제3 네트워크 장치(200-3)로부터 ERROR_MESSAGE(xid=c2)를 받은 후에 다른 네트워크 장치(200-1, 200-2)로 보낸 ADD_MESSAGE들이 실행될 필요가 있는지 판단할 수 있다.

만약, 제 네트워크 장치(200-1)에 보낸 ADD_MESSAGE(xid=a2) 및 제2 네트워크 장치(200-2)로 보낸 ADD_MESSAGE(xid=b2)가 실행할 필요가 없는 것으로 판단된 경우를 설명한다.

이러한 경우, 삭제 메시지(DELETE_MESSAGE)를 이용하여 제1 네트워크 장치(200-1)에 전송한 ADD_MESSAGE(xid=a2) 및 제2 네트워크 장치(200-2)에 전송한 ADD_MESSAGE(xid=b2)를 선별적으로 삭제할 수 있다. 예를 들어, 컨트롤러(100)는 DELETE_MESSAGE(xid=a2)를 제1 네트워크 장치(200-1)에 전송하여 ADD_MESSAGE(xid=a2)를 삭제시키고, DELETE_MESSAGE(xid=b2)를 제2 네트워크 장치(200-2)에 전송하여 ADD_MESSAGE(xid=b2)를 삭제시킬 수 있다.

따라서, 진행 중인 ADD_MESSAGE(xid=a1), ADD_MESSAGE(xid=b1), ADD_MESSAGE(xid=c1)에 대해서는 번들 명령 절차를 계속 진행할 수 있다.

S1040는 번들을 클로즈하는 단계로, S1040 단계를 설명하면 다음과 같다.

ADD_MESSAGE를 모두 전송한 후에 컨트롤러(100)는 클로즈 요청(CLOSE_REQUEST) 메시지를 각각의 네트워크 장치(200-1, 200-2, 200-3)로 보내서 해당 번들을 클로즈(CLOSE)시킬 수 있다.

해당 번들을 클로즈한 후에, 각각의 네트워크 장치(200-1, 200-2, 200-3)는 컨트롤러(100)로 클로즈 응답(CLOSE_REPLY)를 전송할 수 있다. 번들이 클로즈된 후에는 추가적인 ADD_MESSAGE를 받을 수 없으며, 만일 ADD_MESSAGE가 들어오면 각각의 네트워크 장치(200-1, 200-2, 200-3)는 컨트롤러(100)로 에러 메시지를 전송할 수 있다. 각각의 네트워크 장치(200-1, 200-2, 200-3)는 번들을 클로즈한 후에도 제어 메시지들을 실행시키지 않고 임시로 저장할 수 있다.

S1050은 번들을 실행하는 단계로, S1050 단계를 설명하면 다음과 같다.

S1060은 번들 명령의 성공적 실행을 확인하는 단계로, S1060 단계를 설명하면 다음과 같다.

상기 S1010 내지 S1060 단계를 통해, 컨트롤러(100)는 복수의 네트워크 장치(200-1, 200-2, 200-3)에게 번들 명령을 동시에 실행시킬 수 있으며, 번들 명령 실행 중에 일부 네트워크 장치에서 ADD_MESSAGE 실행 중 ERROR_MESSAGE가 발생하더라도 영향을 받는 일부 ADD_MESSAGE만 삭제하고 나머지 ADD_MESSAGE들은 정상적으로 실행하여 번들 명령 절차를 종료할 수 있다.

도 11은 본 발명의 다른 실시예에 따라 ADD_MESSAGE 실행 중 에러가 발생한 경우의 처리 절차를 설명하기 위한 순서도이다.

S1110는 번들 명령 실행을 시작하는 단계로, S1110 단계를 설명하면 다음과 같다.

S1120는 번들 명령을 추가하는 단계로, S1120 단계를 설명하면 다음과 같다.

S1130는 번들 명령 추가 과정에서 에러가 발생한 경우의 처리 단계로, S1130 단계를 설명하면 다음과 같다.

만약, 제 네트워크 장치(200-1)에 보낸 ADD_MESSAGE(xid=a2) 및 제2 네트워크 장치(200-2)로 보낸 ADD_MESSAGE(xid=b2)가 실행할 필요가 있는 것으로 판단된 경우에는 ADD_MESSAGE(xid=a2) 및 ADD_MESSAGE(xid=b2)를 유지시키고 이후 절차를 정상적으로 진행할 수 있다.

S1140는 번들을 클로즈하는 단계로, S1140 단계를 설명하면 다음과 같다.

S1150은 번들을 실행하는 단계로, S1150 단계를 설명하면 다음과 같다.

S1160은 번들 명령의 성공적 실행을 확인하는 단계로, S1160 단계를 설명하면 다음과 같다.

상기 S1110 내지 S1160 단계를 통해, 컨트롤러(100)는 복수의 네트워크 장치(200-1, 200-2, 200-3)에게 번들 명령을 동시에 실행시킬 수 있으며, 번들 명령 실행 중에 일부 네트워크 장치에서 ADD_MESSAGE 실행 중 ERROR_MESSAGE가 발생하더라도 영향을 받는 않는 나머지 ADD_MESSAGE들은 정상적으로 실행하여 번들 명령 절차를 종료할 수 있다.

도 12는 본 발명의 일 실시예에 따라 COMMIT_REQUEST 실행 중 에러가 발생한 경우의 처리 절차를 설명하기 위한 순서도이다.

S1210는 번들 명령 실행을 시작하는 단계로, S1210 단계를 설명하면 다음과 같다.

S1220는 번들 명령을 추가하는 단계로, S1220 단계를 설명하면 다음과 같다.

S1230는 번들을 클로즈하는 단계로, S1230 단계를 설명하면 다음과 같다.

S1240은 번들을 실행하는 단계로, S1240 단계를 설명하면 다음과 같다.

번들을 클로즈한 후에 컨트롤러(100)는 COMMIT_REQUEST 메시지를 각각의 네트워크 장치(200-1, 200-2, 200-3)로 보내서 번들 명령을 실행할 수 있다. 각각의 네트워크 장치(200-1, 200-2, 200-3)는 COMMIT_REQUEST 메시지를 받으면 임시로 저장하고 있던 제어 메시지들을 네트워크 장치(200-1, 200-2, 200-3)에 적용하고 성공적으로 적용하고 나면 COMMIT_REPLY 메시지를 컨트롤러(100)로 전송하고 실행된 번들 명령에 대한 정보를 삭제하지 않고 유지할 수 있다.

그러나, 제3 네트워크 장치(200-3)가 번들 명령 실행 중에 에러가 발생하면, 제3 네트워크 장치(200-3)는 해당 번들 명령에 대한 롤-백(Roll-Back)을 수행한 후 컨트롤러(100)로 ERROR_REPLY 메시지를 전송하고 번들 명령에 대한 정보를 삭제할 수 있다.

S1250는 번들 명령 실행 과정에서 에러가 발생한 경우의 처리 단계로, S1250 단계를 설명하면 다음과 같다.

컨트롤러(100)는 제1 네트워크 장치(200-1) 및 제2 네트워크 장치(200-2)로부터 COMMIT_REPLY 메시지를 받았지만 제3 네트워크 장치(200-3)로부터는 ERROR_MESSAGE를 받은 경우, 제1 네트워크 장치(200-1) 및 제2 네트워크 장치(200-2)의 상태를 그대로 유지할지 아니면 제1 네트워크 장치(200-1) 및 제2 네트워크 장치(200-2)의 상태도 번들 오픈(OPEN) 이전의 상태로 롤-백(Roll-Back)시킬 것인지 판단할 수 있다.

컨트롤러(100)는 제1 네트워크 장치(200-1) 및 제2 네트워크 장치(200-2)의 상태도 번들 오픈(OPEN) 이전 상태로 되돌려야 하는 것으로 판단한 경우에는, 제1 네트워크 장치(200-1) 및 제2 네트워크 장치(200-2)로 복구 요청(RESTORE_REQUEST) 메시지인RESTORE_REQUEST(bundle_id=x1)) 메시지 및 RESTORE_REQUEST(bundle_id=y1) 메시지를 전송할 수 있다.

제1 네트워크 장치(200-1) 및 제2 네트워크 장치(200-2)는 각각 번들 오픈(OPEN) 이전 상태로 롤-백(Roll-Back)한 후에 컨트롤러(100)로 복구 응답(RESTORE_REPLY) 메시지인 RESTORE_REPLY(bundle_id=x1) 메시지 및 RESTORE_REPLY(bundle_id=y1) 메시지를 전송하고 번들 명령에 대한 정보를 삭제한 후에 번들 명령 실행 절차를 종료할 수 있다.

S1250 단계와 같은 처리는, 제1 네트워크 장치(200-1) 및 제2 네트워크 장치(200-2)를 번들 오픈(OPEN) 이전 상태로 되돌려 주기 위해서 S1210 내지 S1240 의 절차를 다시 수행하는 것과 비교하여 장점을 가지고 있다.

즉, 제1 네트워크 장치(200-1) 및 제2 네트워크 장치(200-2)는 COMPLETE_BUNDLE 메시지를 받을 때까지 번들 정보를 유지하고 있기 때문에, 컨트롤러(100)가 간단히 RESTORE_REQUEST 명령만을 이용하여 해당 네트워크 장치를 번들 오픈(OPEN) 이전 상태로 쉽게 롤-백(Roll-Back)할 수 있다.

따라서, S1210 내지 S1250 단계를 통해 컨트롤러(100)는 복수의 네트워크 장치들에게 번들 명령을 동시에 실행시킬 수 있으며, 번들 명령 실행 중에 일부 네트워크 장치에서 ERROR_MESSAGE가 발생하면 간단한 절차로 나머지 네트워크 장치들을 번들 오픈(OPEN) 이전 상태로 롤-백(Roll-Back)시킬 수 있다.

도 13은 본 발명의 다른 실시예에 따라 COMMIT_REQUEST 실행 중 에러가 발생한 경우의 처리 절차를 설명하기 위한 순서도이다.

S1310는 번들 명령 실행을 시작하는 단계로, S1310 단계를 설명하면 다음과 같다.

S1320는 번들 명령을 추가하는 단계로, S1320 단계를 설명하면 다음과 같다.

제어 메시지가 n개 일 경우, ADD_MESSAGE 마다 하나의 제어 메시지를 담아서 n개의 ADD_MESSAGE를 네트워크 장치(200-1, 200-2, 200-3)로 전송할 수 있다. 각각의 네트워크 장치(200-1, 200-2, 200-3)는 ADD_MESSAGE를 받아서 바로 실행시키지 않고 제어 메시지들을 임시 저장소에 저장할 수 있다.

여기서, ADD_MESSAGE는 xid라는 파라미터를 포함할 수 있으며, xid는 컨트롤러(100)-네트워크 장치(200) 연결 안에서는 고유한 값을 사용하여야 하고, 제어 메시지를 구분하기 위해 사용될 수 있다.

S1330는 번들을 클로즈하는 단계로, S1330 단계를 설명하면 다음과 같다.

S1340은 번들을 실행하는 단계로, S1340 단계를 설명하면 다음과 같다.

S1350는 번들 명령 실행 과정에서 에러가 발생하지 않은 네트워크 장치(200-1, 200-2)의 상태를 그대로 유지하는 경우의 처리 단계로, S1350 단계를 설명하면 다음과 같다.

제1 네트워크 장치(200-1) 및 제2 네트워크 장치(200-2)의 상태를 현재대로 유지하는 경우에는, 컨트롤러(100)는 제1 네트워크 장치(200-1) 및 제2 네트워크 장치(200-2)로 각각 완료 번들(COMPLETE_BUNDLE) 메시지인 COMPLETE_BUNDLE(bundle_id=x1) 메시지 및 COMPLETE_BUNDLE(bundle_id=y1) 메시지를 전송할 수 있다

제1 네트워크 장치(200-1) 및 제2 네트워크 장치(200-2)는 이에 대한 응다ㅂ으로, 각각 COMPLETE_REPLY(bundle_id=x1) 메시지 및 COMPLETE_REPLY(bundle_id=y1) 메시지를 컨트롤러(100)로 전송하고 번들 명령에 대한 정보를 삭제한 후에 번들 명령 실행 절차를 종료할 수 있다.

상기 S1310 내지 S1350 단계를 통해 컨트롤러(100)는 복수의 네트워크 장치들에게 번들 명령을 동시에 실행 시킬 수 있으며, 번들 명령 실행 중에 일부 네트워크 장치에서 명령 실행 중 ERROR_MESSAGE가 발생하더라도 컨트롤러(100)의 판단에 따라 다른 네트워크 장치들에 대해서는 번들 명령 실행을 정상적으로 수행하여 완료할 수 있다.

상기에서는 본 발명의 바람직한 실시예를 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다.

100: 컨트롤러 110, 210: 네트워크 장치 제어부
120, 220: 번들 명령 처리부 130, 230: 번들 명령 저장부
140, 240: 플로우 테이블 관리부 150, 250: 네트워크 장치 연동부
200: 네트워크 장치 200-1: 제1 네트워크 장치
200-2: 제2 네트워크 장치 200-3: 제3 네트워크 장치

Claims

소프트웨어 정의 네트워킹에서 번들 명령을 처리하는 방법에 있어서,
컨트롤러가 적어도 하나의 네트워크 장치에 등록된 번들 명령에 대한 상태 확인 요청을 하는 단계;
상기 적어도 하나의 네트워크 장치가 상기 상태 확인 요청에 따라 상기 등록된 번들 명령의 상태를 확인하여 상기 컨트롤러로 상기 등록된 번들 명령에 대한 상태 확인 응답을 하는 단계; 및
상기 컨트롤러가 상기 상태 확인 응답에 기반하여 상기 등록된 번들 명령의 동일 여부를 판단하여 상기 등록된 번들 명령을 처리하는 단계를 포함하는,
컨트롤러와 네트워크 장치 간에 번들 명령을 처리하는 방법.
청구항 1에 있어서,
상기 등록된 번들 명령에 대한 상태 확인 요청을 하는 단계는,
상기 등록된 번들 명령을 구분하기 위해 bundle-id를 활용하는 것을 특징으로 하는,
컨트롤러와 네트워크 장치 간에 번들 명령을 처리하는 방법.
청구항 2에 있어서,
상기 등록된 번들 명령에 대한 상태 확인 응답을 하는 단계는,
상기 bundle-id에 해당하는 상기 등록된 번들 명령의 상태를 확인하는 것을 특징으로 하는,
컨트롤러와 네트워크 장치 간에 번들 명령을 처리하는 방법.
청구항 2에 있어서,
상기 등록된 번들 명령을 처리하는 단계는,
상기 컨트롤러에 저장된 번들 명령과 상기 등록된 번들 명령이 동일한지 판단하는 단계; 및
상기 컨트롤러에 저장된 번들 명령과 상기 등록된 번들 명령이 상이한 것으로 판단됨에 따라 상기 컨트롤러에 저장된 번들 명령을 기준으로 상기 등록된 번들 명령에 대한 삭제, 추가 및 수정 중 적어도 하나의 요청을 하는 단계를 포함하는 것을 특징으로 하는,
컨트롤러와 네트워크 장치 간에 번들 명령을 처리하는 방법.
청구항 4에 있어서,
상기 컨트롤러에 저장된 번들 명령과 상기 등록된 번들 명령이 동일한지 판단하는 단계는,
상기 bundle-id에 해당하는 상기 등록된 번들 명령에 대해 트랜잭션 구분자 및 실행 등록 순서 배열이 상기 컨트롤러에 저장된 번들 명령과 동일한지 판단하는 것을 특징으로 하는,
컨트롤러와 네트워크 장치 간에 번들 명령을 처리하는 방법.
청구항 4에 있어서,
상기 적어도 하나의 네트워크 장치가 상기 등록된 번들 명령에 대한 삭제, 추가 및 수정 중 적어도 하나의 요청에 따라 상기 등록된 번들 명령이 상기 컨트롤러에 저장된 번들 명령과 동일하게 되도록 상기 등록된 번들 명령을 동기화하는 단계를 더 포함하는 것을 특징으로 하는,
컨트롤러와 네트워크 장치 간에 번들 명령을 처리하는 방법.
소프트웨어 정의 네트워킹에서 번들 명령을 처리하는 방법에 있어서,
컨트롤러가 적어도 하나의 네트워크 장치에 번들 명령 실행을 위한 실행 요청(COMMIT_REQUEST) 메시지를 전송하는 단계;
상기 적어도 하나의 네트워크 장치가 상기 실행 요청 메시지에 따른 절차를 실행하고 실행 완료에 대한 응답으로 실행 응답(COMMIT_REPLY) 메시지를 상기 컨트롤러로 전송하는 단계; 및
상기 컨트롤러는 상기 실행 응답 메시지에 대한 확인으로 완료 번들(COMPLETE_BUNDLE) 메시지를 상기 적어도 하나의 네트워크 장치에 전송하는 단계를 포함하는,
컨트롤러와 네트워크 장치 간에 번들 명령을 처리하는 방법.
청구항 7에 있어서,
상기 적어도 하나의 네트워크 장치가 상기 완료 번들 메시지를 수신하여 상기 번들 명령이 정상적으로 실행되었음을 확인하고, 상기 번들 명령에 대한 정보를 삭제함과 동시에 완료 응답(COMPLETE_REPLY) 메시지를 상기 컨트롤러로 전송하는 단계를 더 포함하는 것을 특징으로 하는,
컨트롤러와 네트워크 장치 간에 번들 명령을 처리하는 방법.
소프트웨어 정의 네트워킹에서 번들 명령을 처리하는 방법에 있어서,
컨트롤러가 적어도 하나의 네트워크 장치에 번들 명령 실행을 위한 실행 요청(COMMIT_REQUEST) 메시지를 전송하는 단계;
상기 적어도 하나의 네트워크 장치 각각이 상기 실행 요청 메시지에 따른 절차를 실행하고, 실행 완료에 대한 응답으로 실행 응답(COMMIT_REPLY) 메시지 또는 실행 실패에 대한 응답으로 에러 응답(ERROR_REPLY) 메시지를 상기 컨트롤러로 전송하는 단계; 및
상기 적어도 하나의 네트워크 장치 중 일부가 상기 에러 응답 메시지를 전송함에 따라, 상기 컨트롤러가 상기 실행 응답 메시지를 전송한 네트워크 장치의 상태를 유지할 것인지 결정하는 단계를 포함하는,
컨트롤러와 네트워크 장치 간에 번들 명령을 처리하는 방법.
청구항 9에 있어서,
상기 컨트롤러가 상기 실행 응답 메시지를 전송한 네트워크 장치의 상태를 상기 번들 명령 실행 이전으로 되돌리는 것으로 결정한 경우,
상기 컨트롤러가 상기 실행 응답 메시지를 전송한 네트워크 장치에 복구 요청(RESTORE_REQUEST) 메시지를 전송하는 단계를 더 포함하는,
컨트롤러와 네트워크 장치 간에 번들 명령을 처리하는 방법.
청구항 10에 있어서,
상기 복구 요청(RESTORE_REQUEST) 메시지를 수신한 네트워크 장비가 상기 번들 명령 실행 이전의 상태로 되돌아가고 상기 컨트롤러(100)로 복구 응답(RESTORE_REPLY) 메시지를 전송하는 단계를 더 포함하는,
컨트롤러와 네트워크 장치 간에 번들 명령을 처리하는 방법.
청구항 9에 있어서,
상기 컨트롤러가 상기 실행 응답 메시지를 전송한 네트워크 장치의 상태를 유지하는 것으로 결정한 경우,
상기 컨트롤러가 상기 실행 응답 메시지에 대한 확인으로 완료 번들(COMPLETE_BUNDLE) 메시지를 상기 실행 응답 메시지를 전송한 네트워크 장치로 전송하는 단계를 더 포함하는,
컨트롤러와 네트워크 장치 간에 번들 명령을 처리하는 방법.
청구항 12에 있어서,
상기 실행 응답 메시지를 전송한 네트워크 장치가 상기 완료 번들 메시지를 수신하여 상기 번들 명령이 정상적으로 실행되었음을 확인하고, 상기 번들 명령에 대한 정보를 삭제함과 동시에 완료 응답(COMPLETE_REPLY) 메시지를 상기 컨트롤러로 전송하는 단계를 더 포함하는,
컨트롤러와 네트워크 장치 간에 번들 명령을 처리하는 방법.
소프트웨어 정의 네트워킹에서 번들 명령을 처리하는 방법에 있어서,
컨트롤러가 적어도 하나의 네트워크 장치의 번들 명령에 추가될 제어 메시지를 포함하는 추가 메시지(ADD_MESSAGE)를 상기 적어도 하나의 네트워크 장치로 전송하는 단계; 및
상기 적어도 하나의 네트워크 장치 중에서 일부가 상기 추가 메시지에 대한 실행 과정에서 에러가 발생하여 에러 메시지(ERROR_MESSAGE)를 상기 컨트롤러로 전송함에 따라, 상기 컨트롤러가 상기 추가 메시지를 실행 완료한 네트워크 장치의 상태를 유지할 것인지 결정하는 단계를 포함하는,
컨트롤러와 네트워크 장치 간에 번들 명령을 처리하는 방법.
청구항 14에 있어서,
상기 컨트롤러가 상기 추가 메시지를 실행 완료한 네트워크 장치의 상태를 상기 추가 메시지 실행 이전으로 되돌리는 것으로 결정한 경우,
상기 컨트롤러가 상기 추가 메시지를 실행 완료한 네트워크 장치에 삭제 메시지(DELETE_MESSAGE)를 전송하는 단계를 더 포함하는,
컨트롤러와 네트워크 장치 간에 번들 명령을 처리하는 방법.
청구항 15에 있어서,
상기 삭제 메시지(DELETE_MESSAGE)를 수신한 네트워크 장비가 상기 추가 메시지 실행 이전으로 되돌아가는 단계를 더 포함하는,
컨트롤러와 네트워크 장치 간에 번들 명령을 처리하는 방법.
청구항 14에 있어서,
상기 컨트롤러가 상기 추가 메시지를 실행 완료한 네트워크 장치의 상태를 유지하는 것으로 결정한 경우,
상기 컨트롤러가 추가적인 상기 추가 메시지의 수신을 거부하도록 하는 클로즈 요청(CLOSE_REQUEST) 메시지를 상기 적어도 하나의 네트워크 장치로 전송하는 단계를 더 포함하는,
컨트롤러와 네트워크 장치 간에 번들 명령을 처리하는 방법.
청구항 17에 있어서,
상기 적어도 하나의 네트워크 장치가 상기 클로즈 요청 메시지에 대한 응답으로 클로즈 응답(CLOSE REPLY) 메시지를 상기 컨트롤러로 전송하는 단계를 더 포함하는,
컨트롤러와 네트워크 장치 간에 번들 명령을 처리하는 방법.